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ABSTRACT 


This  manual  is  one  of  a  set  of  three,  produced  to  document  the  Ammunition 
Resupply  Model.  The  Ammunition  Resupply  Model  (ARM)  was  designed  to  simulate 
those  activities  associated  with  amnunition  resupply  in  parallel  with  the  play 
of  existing  war  games.  Its  purpose  is  to  assess  the  capability  of  a  given  TCE 
structure  to  respond  to  the  logistical  demands  nlaced  upon  it  by  various 
numbers  of  ammunition-expending  weaponry  and/or  to  assess  the  capability  of 
existing  or  proposed  resupply  systems  (i.e.  number,  location,  or  sizes  of 
Ammunition  Transfer  Points  (ATP)  and  Ammunition  Storage  Points  (ASP)).  This 
report  contains  a  discussion  of  model  methodology,  data  base  development, 
interface  requirement  with  the  war  game,  and  the  operators  quide.  The  second 
volume  of  the  report  is  the  Programmer's  Manual,  which  consists  of 
descriptions,  logic  flow  diagrams,  and  the  FORTRAN  code  of  all  the  programs 
and  routines  associated  with  the  Ammunition  Resupply  Model.  The  third  volume 
contains  a  description  of  a  standard  heavy  European  Division  data  base  alonq 
with  data  sources. 
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FOREWORD 


In  general,  existing  logistics  models  tend  to  address  resupply 
requirements  in  aggregated  terms,  such  as  tons  per  man  per  day  or  rounds  per 
tube  per  day.  Although  this  approach  has  considerable  merit  for  evaluating 
large  force  structures  engaged  in  sustained  combat,  it  is  inadequate  for 
addressing  logistics  inpacts  of  organizations  engaged  in  short,  intense 
conflict  scenarios. 

Ammunition  expenditures  emerging  from  high  level  (as  opposed  to  high 
resolution)  war  games  have  traditionally  been  either  unconstrained  or  based  on 
a  percentage  of  an  "anticipated"  daily  resupply  capability.  Because  of  this, 
support  analyses  have  not  been  the  product  of  a  concurrent  logistics 
simulation  utilizing  the  same  scenario,  but  have  been  based  on  evaluations 
made  after  game  completion.  This  method  can  paint  a  false  picture  of  a  combat 
unit's  effectiveness.  The  logistics  system,  especially  its  ability  to 
resupply  critical  commodities  such  as  amnunition  and  fuel,  must  be  evaluated 
during  the  course  of  the  simulated  battle. 

To  derive  meaningful  insights  into  the  effects  of  the  airmunition  resupply 
assets  contained  in  different  force  structures  and  their  impact  on  the  combat 
effectiveness  of  the  various  units  within  the  division,  amnunition  resupply 
must  be  evaluated  in  some  detail.  Such  an  evaluation  must  include  simulating 
the  time-consuming  resupply  process  that  places  amnunition  on  individual 
weapon  systems,  as  well  as  the  movement  of  the  different  units'  transportation 
assets  to  secure  additional  ammunition.  It  is  this  concent  that  provides  the 
basis  for  the  Ammunition  Resupply  Model  (ARM) ,  a  concept  that  reflects  the 
real-world  factors  that  affect  amnunition  resupply.  ARM  was,  therefore, 
developed  to  work  in  parallel  with  an  associated  war  game. 

The  concept  for  AM  was  developed  in  October-November  1978,  with  the 
methodology  and  logic  flow  charts  being  completed  in  December  1978.  The 
actual  coding  of  the  model  was  accomplished  from  December  1978  through 
February  1979,  and  the  model  was  operational  in  May  1979.  In  April,  1983  a 
major  overhaul  of  the  Structure  of  ARM  was  completed.  This  documentation 
reflects  those  changes. 
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Ammunition  Resupply  Model 
Technical  Manual 


1.  INTRCDUCTICN. 

a.  Purpose.  The  purpose  of  this  report  is  to  provide  a  detailed 
description  of  the  Ammunition  Resupply  Model  (ARM) .  This  manual  is  an  update 
of  Technical  Report  TR  2-80  published  by  Directorate  of  Studies  and  Analysis, 
US  Army  Combined  Arms  Studies  and  Analysis  Activity,  Ft.  Leavenworth,  KS.  ARM 
was  developed  to  operate  in  parallel  with  a  division  level  war  qame  to  studv 
the  ammunition  resupply  capability  of  alternative  division  organizations  and 
alternative  organizations  of  the  resupply  process  (i.e.  ASP  and  ATP 
configurations) . 


b.  Scope.  This  report  discusses  the  methodologies  and  data  used  in  ARM 
along  with  the  output  (reports)  generated.  Included  in  this  report  is  the 
Qaerators  Manual,  which  outlines  the  procedure  to  be  followed  by  the  model 
operator  in  the  execution  of  ARM. 

c.  Overview. 


(1)  General .  ARM  is  an  event  oriented,  time  sequenced  computer  model 
developed  to  simulate  the  various  functions  associated  with  anmunition 
resupply  from  the  Corps  Storage  Area  (CSA)  down  to  a  given  TOF  structure  to 
respond  to  the  logistical  demands  placed  upon  it  by  various  ammunition 
expenditures.  It  places  these  expenditures  as  demands  on  the  resupply 
network.  While  actual  processes  inside  ASPs  and  ATPs  are  onlv  simulated  bv 
time  delays,  ARM  does  show  shortfalls  in  the  ammunition  resupply  systan  from 
these  areas  by  subjecting  constraints  on  the  resupply  of  unit  trucks  due  to 
availability  of  ammunition  and  material  handling  equipment  (MHE)  for  loading. 
ARM  forces  the  network  to  replace  rounds  on  individual  weapon  systems  and 
their  accompanying  vehicles  at  unit  level  and  send  unit  trucks  back  to 
designated  resupply  points  to  fill  up  and  return.  The  functions  each  truck 
must  perform  are  broken  into  a  series  of  discrete  events  (subroutines).  The 
model  takes  each  truck  through  a  series  of  these  event  subroutines  (with 
operational  availability  and  interdiction  considered)  in  which  actions  are 
completed  and  times  accumulated.  Helicopter  resupply,  interaction  conmand 
decisions,  and  tactical  realism  can  be  incorporated  during  the  game. 

(2)  Gamer  Functions.  The  manual  functions  associated  with  arm  include 
finalizing  of  the  data  base  from  acquired  map  data  for  each  game  played, 
creation  of  associated  events  and  distance  files  and  the  interactive  operation 
of  the  console  (see  Chapter  6).  Events  files  are  used  to  set  up  future 
convoys  for  replenishment.  Distance  files  set  up  for  each  increment  of  the 
war  game  contain  road  distances  from  units  to  servicing  ATP,  ATP  number, 
distance  to  servicing  ASP  and  ASP  number. 


(3)  Game  Resolution.  ARM  is  a  high  resolution  game  that  is  capable  of 
playing  a  brigade  or  division  size  force.  Maneuver  units  are  played  at  the 
battalion  level,  artillery  and  ADA  units  at  the  battery  level,  and  aviation 
units  at  battalion  or  company  level.  Within  the  units,  individual  weapon 
systems  (and  any  dedicated  accompanying  vehicle)  are  reloaded,  and  aimiunition 
dedicated  trucks  deliver  the  aimiunition  to  the  systems  and  make  runs  to 
resupply  points.  A  status  of  all  units  and  of  supply  points  (ATP's  &  ASP's) 
can  be  obtained  at  the  end  of  a  specified  period  of  battle  (usually  4  or  6 
hours) . 

(4)  Stand  Alone  Model.  ARM  was  developed  as  a  stand  alone  model  in  order 
to  retain  the  flexibility  to  support  a  variety  of  attrition  models.  If  the 
attrition  model  does  not  produce  valid  or  usable  aimiunition  expenditures,  the 
capability  exists  within  ARM  to  generate  these  demands.  By  using  intensity 
levels  (low,  med,  high)  and  type  of  engagement  (attack,  defend,  delay)  from 
the  attrition  model,  demand  for  each  unit  can  be  created.  Appendix  A 
describes  this  demand  generation  methodology.  Because  ARM  is  an 
event-sequencing,  time-stepped  model  which  schedules  events  to  occur  at  future 
times,  it  should  not  be  integrated  directly  into  the  attrition  model  it  is 
supporting. 

2.  ASSUMPTICNS/LIMITATICNS. 

a.  Maneuver  units  will  have  the  opportunity  to  accomplish  reload  once 
during  a  specified  period  (4  or  6  hours)  of  combat,  and  anytime  there  is 
unsatisfied  demand. 

b.  Artillery  units  will  reload  when  low  on  ammunition,  which  is  likely  to 
oe  once  each  hour  during  the  battle. 


c.  Aviation  units  will  reload  upon  the  return  of  the  aircraft  to  the  FARP. 

d.  Air  defense  artillery  units  will  reload  once  during  a  specified  period 
(4  or  6  hours)  of  combat. 

e.  Ammunition  trucks  are  dedicated  to  carrying  specified  types  of 
ammunition.  Limited  dual  loading  takes  place.  Artillery  unit  trucks  also 
carry  fuzes  and  powder  on  the  same  truck  with  the  projectiles. 

f.  When  a  weapon  system  is  lost  all  ammunition  on  the  system  is  lost. 

g.  When  a  loaded  truck  is  interdicted,  the  load  is  lost. 

h.  Helicopter  emergency  resupply  will  support  only  155mm  artillery 
batteries. 

i.  Helicopter  resupply  will  originate  from  the  ASP. 
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j.  The  division  slice  of  corps  heavy  lift  helicopters  will  not  exceed  10 
CH47s. 

k.  The  division  slice  of  corps  transportation  assets  for  ammunition 
resupply  will  be  two  medium  truck  companies  of  60  tractors  and  120  trailers 
each.  These  companies  will  provide  ammunition  through-put  from  the  Corps 
Storage  Area  (CSA)  to  the  ATPs  and  provide  replenishment  to  the  ASPs. 

l.  The  model  addresses  the  movement  of  ammunition  frc*n  the  Corps  Storage 
Area  (CSA)  forward  to  the  individual  weapon  systems. 

m.  Only  five  major  types  of  ammunition  for  each  unit  can  be  olaved. 

n.  No  current  capability  exists  for  playing  missiles  such  as  Pershing, 
Chapparrel,  etc. 

o.  ARM  can  be  used  only  in  a  defensive  scenario  unless  alterations  are 
made  to  replenishment  logic. 

p.  Vehicle  failure  rates  are  assumed  to  be  exponentially  distributed;  the 
repair  time  of  a  failed  vehicle  is  log  normally  distributed. 

q.  ARM  simulates  the  flow  of  ammunition  resupply  from  the  CSA  forward. 

As  such  CSA  stockages  are  always  considered  adequate. 

3.  METHODOLOGY. 

a.  General .  The  general  concept  for  the  ARM  simulation  is  based  on  a 
description  of  the  ammunition  resupply  policies  within  a  division  along  with 
the  ammunition  through-put  provided  by  the  corps  support  units.  A  review  of 
these  policies  reveals  a  series  of  discrete  events  (see  figure  3-1) . 

Ammunition  expenditures  during  a  battle  generate  demand  for  more  ammunition. 
The  ammunition  trucks  of  the  various  units  execute  reload  activities  to 
replenish  expended  rounds  on  surviving  weapons.  When  unit  trucks  become 
empty,  they  are  sent  to  a  rear  ammunition  resupply  point  for  another  load. 

The  ammunition  resupply  point  must  have  its  stockage  replenished  in  order  to 
continually  support  the  combat  units.  Essentially,  ARM  processes  the 
ammunition  expenditure  developed  by  a  war  game  or  by  independent  demand 
generation  and  places  this  expenditure  as  a  demand  on  the  resupply  network. 

It  forces  the  network  to  replace  rounds  expended  at  unit  level  by  requirinq 
unit  ammunition  trucks  to  reload  the  surviving  weapon  systems  and,  when  enpty, 
to  go  to  a  designated  resupply  point,  fill,  and  return.  The  model  takes  each 
truck  through  a  series  of  discrete  events  (subroutines)  (operational 
availability  and  interdiction  considered)  in  which  actions  are  completed  and 
times  are  accumulated. 

b.  Major  Events.  The  ammunition  resupply  network  is  broken  down  into 
four  major  events,  each  with  a  number  of  subroutines.  These  major  events  are 
demand,  reload,  resupply,  and  replenishment.  Each  will  be  discussed 
separately  in  order  to  facilitate  understanding  of  the  entire  process  as 
simulated  in  ARM. 
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c-  Demand  and  Reload.  Figure  3-2  is  a  flow  chart  of  the  demand  and 
reload  processes.  The  following  paragraphs  describe  major  events  include  in 

this  area. 

(1)  Demand.  The  demand  for  ammunition  in  ARM  is  provided  as  an  input  to 
the  model  from  some  opposinq  forces  war  game  through  subroutine  RDJIFF.  The 
input  lists  by  unit  the  number  of  each  weapon  systems  remaining  alive,  the 
number  of  survivors  that  actually  fired,  and  the  total  rounds  of  ammunition 
fired  by  the  survivers.  Rounds  fired  by  systems  that  were  killed  have  been 
subtracted  out.  Weapon  systems  which  are  added  to  the  battle  are  also 
reloaded.  Within  ARM  the  subroutine  DEMAND  performs  the  function  of  takinq 
any  unsatisfied  demand  of  a  unit  (demand  that  has  not  been  satisfied  when  the 
DEMAND  event  is  called)  and  combining  it  with  newly  generated  demand.  If  the 
unit  is  artillery,  the  total  demand  for  each  type  of  ammunition  is  divided  by 
H  to  reflect  the  expenditure  during  each  hour  of  the  H  hour  critical  incident 
of  the  war  game  for  which  ARM  was  developed.  These  nul Ises  can  be  through t  of 
as  times  when  ARM  looks  to  see  if  weapon  systems  need  ammunition.  The 
subroutine  then  scans  the  trucks  at  the  unit  to  find  one  with  the  rioht 
ammunition.  In  the  particular  case  of  1 S5mm  artillery  units,  DEMAND  compares 
the  actual  demand  (expenditure)  against  the  sum  of  the  current  supply  and  th<=> 
armo-on-trucks.  If  the  difference  is  unusually  high  (e.q.,  no  trucks  at  the 
unit  and  current  supply  low)  it  is  compared  against  the  critical  resupply 
level.  If  the  critical  resupply  level  has  been  reached,  DEMAND  will  schedule 
an  emergency  reload  event  by  helicopter  (HELARV) .  If  a  truck  was  found  with 
the  correct  ammunition  on  board  a  RELOAD  event  is  scheduled.  Upon  completion 
of  the  DEMAND  event,  the  unit's  demand  will  have  been  undated  and  a  reload 
event  scheduled.  For  artillery  units  the  DEFIANT)  event  will  reschedule  itself 
to  occur  again  60  minutes  from  the  present  time. 

(2)  Reload.  For  a  given  unit  for  which  reload  has  been  scheduled  the 
subroutine  RELOAD  performs  the  actual  replacement  of  rounds  of  arrmunition 
expended  by  rounds  carried  on  unit  trucks.  First  a  type  of  ammunition  is 
selected,  then  the  unit  queue  is  searched  for  a  truck  hauling  that  type  of 
ammunition.  If  a  truck  is  found,  the  following  calculations  are  made:  (1) 
the  number  of  weapon  systems  that  can  be  reloaded  by  this  truck  -  a  function 
of  the  demand  and  the  truck's  load,  (2)  the  total  reload  time,  and  (3)  the 
return  time  to  the  combat  trains  or  truck  assembly  area.  The  reload  time  is 
calculated  by  the  following  equation: 

Rtime^j^  =  2  *  Trvtme^  +  W(Aj  +  B-j  (SRds/Wpn)) 

where  Rtime^j^  «  the  time  required  to  complete  reload  for  weapons 

i  with  round  j  at  unit  k. 

TRVIMEk  =  travel  time  from  combat  trains  or  truck  assemblv 
areas  to  the  weapon  positions 
W  =  number  of  weapons  that  can  be  loaded  by  a  truck 
(depends  on  truck  load) 

A^  =  set  up  time  p.*r  weapon  i  (time  for  weapon  to 
prepare  itself  to  take  on  ammunition) 

B-;  =  reload  time  per  round  (obtained  from  I  RETIME 
file) 
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Having  completed  reload  of  the  weapons  the  truck  is  scheduled  to  return  to  the 
combat  trains  or  assembly  area  if  there  are  rounds  on  board  or  it  is  scheduled 
to  go  pick  up  another  load.  Therefore,  RELOAD  will  schedule  a  unit  arrival 
(UNTARV) ,  returning  the  truck  to  the  unit  to  wait  for  another  demand,  or  a 
unit  departure  (IWTDEP) ,  sending  it  after  another  load. 

(3)  Unit  Arrival  (UNTARV) .  The  subroutine  UNTARV  brings  the  truck  back  to 
the  unit  combat  trains,  in  the  case  of  maneuver  units,  or  assembly  areas  tor 
artillery  units.  Upon  arrival,  the  arrmo-on-truck,  an  element  of  the  unit 
status,  is  updated.  Since  this  event  is  scheduled  from  other  subroutines,  a 
check  is  made  for  unsatisfied  demand  of  the  particular  tvoe  of  ammunition 
carried  on  the  truck.  If  there  is  an  unsatisfied  demand,  a  RELOAD  event  is 
immediately  scheduled;  otherwise,  the  truck  waits  for  another  RELOAD  event  to 
occur. 

(4)  Unit  Departure  (UNTDEP) .  If  upon  completion  of  a  reload  event  a  truck 
is  empty,  a  unit  departure  (UNTDEP)  event  is  scheduled.  This  subroutine 
checks  for  the  type  of  ammunition  in  lowest  supply.  If  this  tyoe  is  stocked 
at  the  ATP,  an  arrival  time  at  the  servicing  ATP  is  calculated  and  an  ATP 
arrival  (ATPARV)  event  scheduled.  The  arrival  time  is  based  upon  the  distance 
from  the  unit  to  the  ATP  and  the  average  speed  of  the  truck.  If  the 
ammunition  is  not  stocked  at  the  ATP  then  an  arrival  time  at  the  ASp  is 
calculated  and  an  ASP  arrival  (ASPARV)  event  scheduled. 

(5)  Operational  Availability.  Every  time  a  truck  moves,  a  check  is  made 
of  its  operational  availability  in  subroutine  OPERA.  Each  truck  has  its  own 
clock,  which  keeps  track  of  the  hours  of  operation  since  it  last  failed.  At 
the  start  of  the  game  all  trucks  are  initialized  with  a  time  since  last 
failure  based  on  an  exponential  distribution.  Each  time  a  truck  moves,  the 
time  length  of  the  move  is  subtracted  from  the  time  remaining  until  the  next 
failure.  When  the  time  remaining  becomes  zero  the  truck  status  is  changed  and 
its  movement  delayed.  The  length  of  time  a  truck  is  inactive  is  based  on  a 
log  normal  distribution.  OPERA  is  called  from  any  event  subroutine  that 
involves  truck  movement  and  or  activity  (MHE) . 

(6)  Interdiction.  The  interdiction  subroutine  (INTRDK)  determines  whether 
a  truck  about  to  execute  a  move  will  be  interdicted  and,  if  so,  assesses  a 
time  delay  for  providing  a  replacement  truck.  For  interdiction  purooses,  the 
combat  arena  is  subdivided  into  two  zones.  Zone  one  extends  from  the  line  of 
contact  to  the  brigade  rear  boundary.  Zone  two  consists  of  the  area  from  the 
brigade  rear  boundary  to  the  corps  storage  area.  Unit  trucks  forward  of  the 
ATP  are  considered  to  be  in  zone  one,  where  they  are  susceptible  to  being  hit 
by  artillery  fire.  Unit  trucks  moving  from  the  ATP  to  the  ASP  and  all  S&p 
type  trucks  are  considered  to  move  in  zone  two,  where  they  are  subiect  to 
attacks  by  aircraft.  The  attrition  model  provides  the  number  of  trucks  killed 
by  artillery  fire  during  the  battle  being  simulated.  In  order  to  determine 
which  trucks  are  interdicted  it  is  first  necessary  to  take  the  total  number  of 
trucks  killed,  as  given  by  the  attrition  model,  and  multiply  it  by  the 
precentage  of  all  trucks  that  carry  ammunition.  This  number  is  then  entered 
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into  a  data  file  as  the  total  number  of  zone  one  trucks  to  be  interdicted  this 
battle  period.  In  order  to  spread  this  number  over  as  many  units  as  possible, 
another  number  between  15  and  30  is  selected  at  randan,  which  is  used  as  a 
controlled  cycle  number  that  we  will  call  Y.  Each  time  a  truck  is  scheduled 
for  move  it  is  sent  through  IMTRDK,  where  a  counter  is  maintained,  when  the 
yth  truck  enters  IMTRDK  it  is  the  one  interdicted,  and  a  time  delay  is 
assessed  before  a  replacement  truck  can  be  provided.  The  counter  is  then 
reset  to  0  and  started  again.  This  procedure  is  continued  until  the  total 
number  of  trucks  that  were  to  be  interdicted  has  been  reached.  This  method 
comes  very  close  to  representing  reality  since  one  would  expect  that  units 
that  fire  often  are  more  susceptible  to  receiving  counterfire  and  therefore 
lose  more  trucks.  In  ARM,  the  units  that  fire  more  require  the  unit  trucks  to 
move  more  frequently.  The  number  of  trucks  to  be  interdicted  in  zone  two  are 
selected  by  the  military  gamer.  The  number  is  usually  less  tha~  the  number  of 
trucks  interdicted  in  zone  one.  The  delay  time  associated  with  interdiction 
is  a  constant  representing  average  replacement  time  to  division  rear.  Since 
10-ton  unit  trucks  are  limited  in  inventory  stockage,  all  interdicted  10-ton 
trucks  are  replaced  with  trucks  having  a  5-ton  carrying  capability. 

d.  Resupply.  Figure  3-3  is  a  flow  chart  of  the  resupply  process. 

Resupply  of  unit  ammunition  trucks  consists  of  three  distinct  steps:  (1) 
finding  available  ammunition  (2)  locating  MHE  to  reload  the  truck  (except  for 
MLRS  which  will  be  discussed  separately)  (3)  reloading  of  ammunition  onto  the 
unit  truck.  Since  the  most  used  types  of  ammunition  are  available  at  ATPs, 
the  discussion  of  the  resupply  process  will  begin  with  a  unit  truck  arriving 
at  an  ATP  (subroutine  ATPARV) . 

(1)  Arrival  at  an  ATP  (ATPARV) .  The  ATPARV  subroutine  determines  the  type 
of  ammunition  the  arriving  truck  requires  and  the  quantity  of  rounds  needed. 

It  then  checks  for  availability  of  that  ammo  at  the  ATP.  If  supply  is 
sufficient  to  service  this  truck  and  all  other  trucks  already  waiting  for 
resupply  of  that  ammunition  type,  the  truck  waits  to  be  served.  If  the 
ammunition  is  an  artillery  type,  a  further  check  is  made  to  make  sure 
sufficient  powder  is  on  hand  (ARM  does  not  explicitly  count  fuzes  for 
artillery  ammunition) .  If  the  supply  is  insufficient  to  provide  the  truck 
with  a  load  once  it  reaches  the  head  of  the  line,  it  is  sent  to  the  ASP  by 
scheduling  an  ASP  arrival  event  (ASPAKV) .  The  time  of  arrival  at  the  ASP  is 
determined  by  distance  between  ATP  and  servicing  ASP  and  average  truck  speed. 
If  there  are  no  other  trucks  waiting  to  be  serviced,  an  ATP  event  is  scheduled 
at  that  time,  otherwise  the  truck  waits  at  the  bottom  of  the  queue  for  the 
release  of  a  server  (MHE) .  In  the  case  of  trucks  with  organic  cranes 
(currently  MLRS  carrying  vehicles)  a  check  is  made  to  see  the  number  of  trucks 
at  the  ATP  that  are  currently  taking  on  MLRS.  If  there  are  less  than  three, 
an  ATP  event  is  scheduled;  otherwise  it  must  wait  for  a  truck  to  finish  its 
self-load.  After  a  server  (MHE)  has  been  located  to  reload  the  unit  trucks, 
an  ATP  event  is  scheduled. 
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(2)  ATP  Event*  The  ATP  event  (subroutine  ATP)  simulates  activities  which 
take  place  at  the  ATP.  The  event  begins  by  locating  an  idle  S&P  trailer 
containing  the  type  of  ammunition  needed.  If  no  S&P  is  available  for  loading, 
i.e.  all  S&P  with  the  correct  ammunition  are  busy  reloading  other  unit  trucks, 
the  truck  waits.  When  an  available  S&P  is  located,  the  unit  truck  is  loaded, 
the  number  of  rounds  loaded  are  decremented  from  the  supply  on  the  S&P,  and 
rounds  issued  from  the  ATP  are  incremented.  In  the  case  of  artillery 
ammunition,  an  S&P  containing  powder  is  also  decremented.  The  loaded  unit 
truck  is  then  scheduled  for  arrival  back  at  the  unit  (UOTARV) .  If  the  S&P 
trailer  is  empty,  a  tractor  pulling  a  full  trailer  arriving  for  replenishment 
of  the  ATP  will  hitch  up  to  the  enpty  trailer  and  return  it  for  restockinq  at 
the  CSA  or  ASP  (depending  on  its  place  of  origin). 

(3)  Resupply  at  an  ASP.  Unit  trucks  are  serviced  at  an  ASP  for  one  of 
three  reasons:  the  desired  amnunition  is  not  stocked  at  the  ATP;  the  truck 
was  "bumped"  from  the  servicing  ATP  due  to  lack  of  arrmunition;  this  is  a 
replacement  for  a  unit  truck  which  has  been  interdicted  (all  amnunition  on  an 
interdicted  truck  is  lost) . 

(4)  ASP  Arrival  (subroutine  ASPARV) .  A  unit  truck  arriving  at  an  ASP 
follows  essentially  the  same  procedure  as  an  arrival  at  an  ATP.  The  major 
difference  occurs  when  there  is  not  sufficient  amnunition  at  the  ASP  to 
resupply  the  unit  truck.  In  this  case  a  subroutine  (ASPCK)  is  called  which 
checks  available  ammunition  at  an  adjoining  ASP.  If  insufficient,  then  "rear" 
ASPs  which  are  being  established  during  the  course  of  the  war  game  are  checked 
for  availability.  If  supply  is  adequate  at  another  ASP,  then  the  unit  truck 
is  scheduled  for  an  ASP  arrival  event  at  the  correct  ASP.  If  no  ammunition  is 
available  at  any  ASP,  the  unit  truck  is  held  at  the  original  ASP. 

(5)  ASP  Event.  An  ASP  event  is  similar  to  an  ATP  event  exceot  that 
ammunition  is  not  only  on  S&P's,  it  is  also  stored  on  the  ground,  therefore, 
if  no  trailer  is  available,  the  unit  truck  is  resupplied  from  ground  stockage. 

e.  Replenishment .  Replenishment  of  stockage  at  ASPs  and  ATPs  are 
accomplished  in  ARM  by  the  scheduling  of  convoys.  Figures  3-4a  and  3-4b  are 
flow  charts  of  the  major  replenishment  activities.  The  reader  should  refer  to 
it  in  reading  the  next  paragraphs.  Discussion  will  begin  with  ATP 
replenishment. 

(1)  ATP  replenishment.  In  accordance  with  current  plans,  ARM  supplies 
approximately  20  percent  of  stockage  at  ATPs  from  ASPs,  80  percent  from  the 
CSA.  When  a  S&P  trailer  is  emptied  at  the  ATP,  a  determination  is  made  (in 
Subroutine  ATP)  whether  it  originated  at  the  ASP  or  the  CSA,  it  is  then  put 
into  the  correct  queue  to  wait  for  an  incoming  tractor.  Figure  3-4a  is  a  flow 
chart  of  major  activities  involved  in  replenishment  of  ATP  supplies. 

Discussion  of  these  activities  will  begin  with  an  empty  S&P  trailer  at  the 
ATP.  Determination  is  made  whether  this  trailer  originated  at  the  servicing 
ASP  or  at  the  CSA. 
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(a)  Replenishment  from  ASP.  When  a  tractor  carrying  replenishment 
ammunition  from  the  ASP  to  the  ATP  arrives  at  the  ATP  (subroutine  ATPAR2) ,  the 
rounds  of  the  full  tractor  are  added  to  the  stockage  at  the  ATP,  an  empty 
trailer  is  located  and  the  S&P  is  then  scheduled  back  to  the  ASP  (Subroutine 
ASPARl) .  At  the  ASP,  a  check  is  made  to  locate  a  full  trailer  of  the  correct 
ammunition.  If  one  is  found  the  tractor  hitches  up  and  is  scheduled  for 
return  to  the  ATP  with  a  time  delay  of  30  minutes  for  processing  plus  travel 
time  back  to  the  ATP;  otherwise  the  empty  trailer  is  filled  and  returned. 

(b)  Replenishment  from  CSA.  Empty  trailers  are  scheduled  to  return  to 
the  CSA  (subroutine  CSAARV)  from  the  ATP  through  subroutine  ATPAR1  when  a 
tractor  is  available.  Upon  arrival  at  the  CSA  a  delay  time  is  assessed  to 
simulate  either  location  of  a  full  trailer  carrying  the  same  ammunition  or 
load  time  for  an  enpty  trailer.  The  vehicle  is  then  held  until  three  S&Ps 
are  full  and  then  a  convoy  of  the  3  S&Ps  are  scheduled  to  depart  the  CSA 
(subroutine  CSADEP)  one  minute  apart.  In  order  to  simulate  the  activities  of 
the  Division  Ammunition  Officer  (DAO),  the  S&P  arrives  at  the  DAO  location 
(somewhere  rear  of  the  ATPs)  at  which  time  a  check  is  made  of  the  stockage 
objective  for  the  type  of  ammunition  the  trailer  is  carrying  at  the  assiqned 
ATP.  This  stockage  objective  is  input  as  part  of  the  data  base  and  should  be 
adjusted  as  the  game  progresses  to  reflect  shorter  or  longer  distances  between 
the  ATP  and  CSA  (and  hence  shorter  or  longer  travel  times  for  the  S&Ps)  which 
could  result  in  too  little  or  too  much  stockage  at  the  ATP.  If  the  stockaae 
level  at  the  assigned  ATP  has  not  been  net,  then  the  S&P  is  scheduled  for 
arrival  at  that  ATP.  If  stockage  levels  are  already  high  at  the  assigned  ATP, 
a  determination  is  made  whether  other  active  ATPs  need  this  ammunition,  if  so 
the  S&P  is  diverted  to  the  ATP  needing  supplies.  If  no  ATPs  need  the 
ammunition  it  is  sent  to  the  assigned  ASP. 

(2)  ASP  replenishment.  All  replenishment  of  ASPs  come  from  the  CSA. 
Because  of  the  length  of  time  required  to  set  up  and  stock  an  ASP,  stockaae  of 
rearward  ASPs  is  usually  ongoing  while  active  ASPs  are  replenished.  When 
movement  of  the  FEBA  requires  closing  of  an  ASP,  replenishment  convoys  are 
discontinued  and  existing  stocks  are  utilized  until  depletion.  Figure  3-4h  is 
a  flow  chart  of  ASP  replenishment  logic  in  ARM. 

(a)  Storage  of  ammunition.  An  attempt  is  made  to  offload  all  ammunition 
onto  the  ground  so  that  S&Ps  can  return  to  the  CSA  for  more  ammunition,  when 
a  full  S&P  arrives  at  the  ASP  (event  ASPAR2) ,  the  ammunition  on  hand  at  the 
ASP  is  incremented.  A  search  is  made  to  see  if  the  full  trailer  load  is 
needed  for  stockage  of  ATPs,  if  so  a  delay  to  simulate  unhitchinq  and  other 
related  activities  is  assessed  and  the  full  S&P  is  returned  to  the  ATP.  The 
empty  vehicle  then  waits  until  7  empty  S&Ps  have  accumulated  when  they  are 
scheduled  to  arrive  back  at  the  CSA  (event  CSAARV)  one  minute  apart.  If  the 
ammunition  is  not  needed  for  stockage  of  ATPs,  a  search  is  made  for  an  idle 
server  to  off-load  ammunition  onto  the  ground.  If  none  are  found,  the  S&P 
waits  until  one  is  available. 
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(b)  Replenishment  from  the  CSA.  When  an  empty  S&P  arrives  at  the  CSA,  a 
check  is  made  to  determine  which  type  of  ammunition  is  most  needed  at  any  ASP 
which  is  receiving  stockage.  If  all  ASPs  have  achieved  their  stockaae 
objective*  lot  all  Ammo  types  the  truck  waits  at  the  CSA. 

f.  Corps  Storage  Area.  ARM  does  not  address  replenishment  of  the  CSA. 
Stockage  of  ammunition  is  always  considered  adequate.  S&Ps  are  assessed  time 
delays  to  simulate  loa^.ng,  but  no  discrete  events  take  place  nor  is 
availability  of  MHE  considered. 

4.  DEMAND  GENERATION. 

a.  General.  The  RANMCD  program  was  developed  for  two  purposes:  to 
generate  the  ammunition  demand  required  by  the  ARM  simulation  and  to 
facilitate  the  creation  and  modification  of  the  ammunition  demand  files. 

Demand  generation  is  based  upon  a  24-hour  period  which  has  been  divided  into 
two  12-hour  phases  (day  and  night).  Each  phase  is  comprised  of  several  (1-3) 
critical  incidents  (CIs) .  In  a  given  phase,  a  total  demand  figure  will  be 
generated  for  every  active  weapon  system  in  each  unit.  Each  of  the  total 
demand  figures  will  then  be  distributed  across  the  critical  incidents 
comprising  the  phase  and  stored  in  the  demand  files. 

b.  Controlling  Factors.  The  factors  affecting  demand  generation 
include:  weapon  type,  number  of  weapons  short  (weapons  receiving  ammunition) , 
number  of  maintenance  returns  and  war  reserves,  number  of  critical  incidents 
comprising  the  phase,  the  type  of  phase,  the  MCPP  level  and  battle  intensitv. 
The  program  obtains  these  factors  through  user  incut.  As  discussed  in 
Appendix  A,  the  weapon  type  and  the  unit  battle  intensity  factor  determine  the 
high  and  low  firing  rates  for  each  weapon  system?  the  type  of  phase  (day  or 
night)  and  the  MCPP  level  serve  as  degradation  factors;  and  maintenance 
returns  and  war  reserves  determine  the  number  of  basic  loads  to  add  to  the 
total  combat  demand.  (It  has  been  assumed  that  weapon  systems  added  to  a  unit 
as  war  reserves  arrive  with  no  ammunition  on  board  and  maintenance  returns 
arrive  with  1/2  a  basic  load.  Returns  are  made  at  the  end  of  a  critical 
incident  (Cl)  and  therefore  do  not  expend  any  ammunition  until  the  followinq 
Cl.) 


c.  Demand  Generation  Process.  The  program  retrieves  the  pertinent  hiqh 
and  low  limits  from  the  Ammunition  Consumption  Windows**  stored  in  the  data 
section  and  takes  cheir  difference.  A  random  number  between  0  and  1  is  drawn 
from  a  uniform  distribution  and  multiplied  by  the  difference.  The  lower 
consumption  limit  is  then  added,  producing  a  demand  figure  for  the  total  day, 
as  in  equation  1. 

total  day  demand  =  (high  -  low)  *  random  draw  +  low  limit  (1) 


*See  para  (b)  p  13  for  discussion  on  Stockage  Obiectives. 

**See  Appendix  A  for  explanation  of  consumption  windows. 
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The  total  demand  for  a  phase  is  then  obtained  by  degrading  the  total  dev 
figure  by  the  phase  factor  (.6  for  day;  .4  for  night)  and  by  the  MOP!  factor 

as  in  equation  2. 

total  phase  =  total  day  *  phase  factor  *  MOPD  factor  (2) 

To  distribute  the  total  demand  across  the  cr’ti'-al  incidents  (Cl si  comprising 
the  phase,  a  new  random  number  is  drawn  for  each  critical  incident.  These  01 
draws  are  then  summed  and  the  proportion  created  by  dividing  a  Cl  draw  bv  the 
sum  is  multiplied  by  the  total  phase  demand  to  determine  the  demand  ner  tube, 
as  in  equation  3. 

demand/tube  =  phase  demand  *  Cl  dr aw /accumulated  Cl  draw  (3) 

The  demand  per  tube  is  then  multiplied  by  the  number  of  weapons  short  (weanons 
firing)  to  produce  the  total  combat  demand  for  that  critical  incident. 
Ammunition  requirements  are  then  assessed  for  the  war  reserves  and  maintenance 
returns  and  added  to  the  combat  danand:  one  basic  load  for  each  combat  reserve 
and  one-half  basic  load  for  each  maintenance  return.  The  resulting  figure 
comprises  the  total  demand,  as  in  eguation  4. 

total  demand  =  demand/tube  *  wpns  short  +  (load  *  (war  +  mnt/2))  (4) 

(1)  Because  Divad  guns  fire  in  90  round  bursts,  total  demand  is  rounded 
to  the  nearest  integer  divisible  by  90. 

(2)  Because  artillery  weapons  fire  several  types  of  ammunition,  the  total 
demand  is  distributed  according  to  the  distributions  listed  below: 


HE 

I  CM 

RAP 

CLGP 

Other 

155mn 

0.16 

0.65 

0.11 

0.04 

0.04 

8  in 

0.20 

0.68 

0.12 

(3)  For  attack  helicopter  units,  differences  in  operational  technig  •  . 
and  employment  methods  necessitate  a  difference  in  demand  generation, 
described  above,  the  difference  between  the  high  and  low  consumption  windows 
is  obtained,  multiplied  by  a  random  number  and  added  to  the  lower  limit. 

This  value  is  then  multiplied  by  the  number  of  helicopters  flying  missions  in 
one  critical  incident  and  constitutes  the  total  combat  demand  for  that 
critical  incident.  MOPP  and  phase  degradation  factors  are  not  applied; 
maintenance  returns  and  combat  reserves  are  calculated  as  above  to  determine 
the  total  demand,  as  in  equation  5. 


ah  demand  =  ((h-l)*draw+i)  *  wpns  sht  +  ( load (war +mnt/2) ) 


(5) 
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d.  Ammunition  Demand  Files.  The  demand  files  are  direct  access  files 
each  dedicated  to  one  critical  incident  and  consisting  of  a  list  of  attributes 
for  each  unit  used  in  ARM.  Each  unit  in  the  file  reDresents  one  record  of  the 
file. 

(1)  The  unit  attributes  may  ! >e  viewed  as  a  5x6  matrix  in  which  each  row 


represents  a  different 

ammunition  type  and 

each 

column 

contains 

a  different 

ammunition  feature  (ammunition  code,  number  of 

weapons 

alive,  weapons  short 

attack  helicopters  per 

cell,  total  danand) 

ANMO 

WPNS 

WPNS 

AHS/ 

TOTAL 

UNIT 

CCDE 

LIVE 

SHRT 

CEIL 

DEMAND 

FA-2ACR 

4 

7 

7 

0 

140 

5 

7 

7 

0 

564 

11 

7 

7 

0 

95 

12 

7 

7 

0 

35 

13 

7 

7 

0 

35 

0 

0 

0 

0 

0 

Currently,  each  file  contains  thirty  attributes  for  each  of  the  seventy-five 
units  listed  in  ARM.  Up  to  fifty-five  such  files  (one  for  each  of  the 
fifty-five  critical  incidents)  can  be  created  without  proqram  modification. 

(2)  RANMCD  accesses  the  demand  files  through  the  use  of  an  SSG  runstream 
(RUNS).  The  runstream  assigns  the  permanent  files  and  permits  multiple 
versions  (cycles)  of  each  file  to  co-exist.  The  RANMCD  proqram  reads  from  the 
writes  to  the  files  assiqned  bv  the  runstream. 

e.  Editing  Features. 

(1)  An  integral  part  of  the  editing  process  is  the  INFO  routine.  INFO  is 
an  internal  reference  routine  which  provides  access  to  specific  information 
during  program  execution.  The  success  of  the  editing  process  is  dependent 
upon  the  accuracy  and  judgment  involved  in  user  responses  to  program  emeries. 

Incorporated  into  each  major  query  is  the  Darenthetical  conment  (INFO  =  _ ). 

If  the  user  enters  the  INFO  value  in  response  to  the  Query,  a  message 
containing  information  pertinent  to  that  Query  will  be  displayed.  For 
example,  the  INFO  message  in  response  to  a  auery  for  a  weapon  system  code  will 
display  the  list  of  available  systems  by  name  and  code  number;  the  INFO 
response  to  an  option  query  will  explain  *-he  effect  of  each  of  the  options 
listed. 

(2)  There  are  four  fundamental  operations  available:  print  file;  copy 
sequence;  change-by-row;  and  edit  'new  demand. 

(a)  The  print  file  operation  offers  the  choice  of  havina  the  files 
printed  locally  or  not.  When  printed  local !v,  the  user  can  select  specific 
units  to  be  listed.  The  listing  will  give  the  unit  attributes  for  the  entire 
phase.  When  the  other  alternative  i-  sole-. 'ted,  ex-h  file  is  read  into  a 
report  file  to  be  synmed  to  a  specific  loca*-.«in  for  later  printing.  The 
report  file  will  be  retained  for  later  re'etence. 


(b)  The  copy  sequence  operation  is  designed  to  allow  the  user  to  coov  one 

sequence  (of  one  or  more  units)  into  another  within  the  same  file. 

(c)  Change-by-row  is  a  hand-insert  method  used  for  modifying  portions 

(rows)  of  units  in  individual  files.  The  primary  editing  process  operates  at 

the  phase  level,  manipulating  values  for  several  files  at  one  time. 

Change-by-row  permits  the  user  to  alter  the  values  in  one  critical  incident 
without  affecting  the  values  in  the  remainder  of  the  chase.  A  copy  feature 
also  provides  the  only  means  for  copying  individual  rows  into  new  units 
without  disturbing  the  values  in  the  ranainder  of  the  unit. 

(d)  The  edit/new  demand  operation  is  the  main  editing  orocess  of  the 
program.  It  operates  on  an  option-selection  basis,  permitting  the  user  to 
select  only  those  options  desired.  Twelve  options  are  available: 


1. 

Weapons  alive 

7. 

Instant  demand 

2. 

Weapons  short 

8. 

Unit  copy 

3. 

Weapon  type 

9. 

Auto  1 ist 

4. 

Attack  helicopters 

10. 

Auto  save 

5. 

Maintenance  returns 

Li  . 

New  demand 

6. 

War  reserves 

12. 

By  a.iino  code 

The  first  seven  consist  of  different  types  of  entries  which  may  need  to  he 
made;  the  next  four  consist  of  different  functions  that  can  be  per formed;  the 
last  provides  the  user  with  a  method  of  selecting  specific  ammunition  tvoes  to 
alter.  The  user  can  select  any  combination  of  the  twelve  which  suits  his 
needs.  The  user  instructions  that  follow  provide  a  step-by-step  illustration 
of  how  this  process  works. 

f.  User  Instructions.  User  instructions  are  divided  into  two  columns. 

The  left-hand  column  contains  program  messaqes  and  sample  user  responses. 

User  responses  are  underlined,  program  messages  and  machine  prompts  are  not. 
The  right-hand  column  contains  explanatory  remarks. 


PROGRAM  MESSAGES 
AND  USER  RESPONSES 

0SSG  DEMAND  RUNS 

SSG  .  .  .05/23/83 
12:54:21 

SGS 

NUMCIS  3 


COMMENTS 


The  SSG  runstream  will  access  the 
permanent  demand  files. 


The  number  of  files  to  be  edited  is 
entered.  This  number  should  be  equal  to 
the  number  of  CIs  in  the  phase  (1,  2,  or 
3).  Here,  3  CIs  will  be  edited. 
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PROGRAM  MESSAGES 
AND  USER  RESPONSES 


REPORT 


NEW  01,  02,  03 


OLPFILE  01,  02,  03 
NEWFILE  01,  02,  03 


£ 

END  SSG.  ERRORS:  /0/0/0 


COMMENTS 


Report  is  entered  when  the  user  intends  to 
create  a  printable  file  of  the  data  files. 
Following  the  comDletion  of  the  editinq 
process,  the  report  files  can  be  synrned  to 
a  printer  for  listing. 

The  user  now  must  select  one  of  two  methods 

The  NEW  irethod  is  used  when  no  files  exist 
to  be  read.  Here,  demand  files  for  CTs  01, 
02,  and  03  will  be  created. 

This  method  allows  the  user  to  copy  from 
existing  files  into  new  files.  Tn  this 
example,  the  old  file  01  will  be  read  into 
a  new  cycle  of  file  01  and  into  a  new  file 
03.  The  old  file  13  will  be  read  into  file 
02.  (Note:  the  file  numbers  are  two-diqit 
numbers  between  01  and  55  which  correspond 
to  the  actual  Cl  numbers  involved.) 

This  entry  indicates  that  all  required 
information  has  been  entered. 


READY 

READY 

READY 


The  number  of  READY  prompts  will  depend 
upon  the  number  of  CIs  involved  and  the 
method  selected  above. 


The  user  is  now  ready  to  beqin  execution  of 
the  editing  proqram,  RANMCP. 

gXQT  DEMAND. RANMCD 

ENTER  FILE  TREATMENT. (INF 0=0)  Select  the  treatment  which  is  appropriate 

1.  New  files  from  old  to  the  SSG  runstream. 

2.  New  files  from  scratch. 

3.  Copy  sections. 
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PROGRAM  MESSAGES 

AND  USER  RESPONSES  COMENTS 


0  This  entry  will  list  the  INFO  messaue. 

(1)  is  used  when  creating  a 
new  file  or  cycle  from  an 
old  file. 

(2)  is  used  with  the  NEW  option 
in  the  SSG  runstream. 

(3)  would  be  used  in  the  rare 
instances  when  only  part  of 
an  old  file  is  to  be  copied 
into  the  new  one 


The  second  ontion  is  selected. 


ENTER  THE  NO.  CF  CIS  AND  EACH 
Cl  NO.  (INFO=0,0) 


The  first  entrv  qiv*m  the  numbers  ot  files 
to  he  edited.  The  refraining  entries  arfj 
used  only  for  printouts  and  will  not  affect 
the  files. 


3,  1,  2,  3 


There  will  be  1  Cls  mo  thev  will  re 
labeled  Cl  1 ,  Cl  ?,  and  Cl  3. 


ENTER  METHOD  TO  BE  USED.  (INFOO) 

1.  Units  in  sequence 

2.  Random  units 

3.  Group 


Permits  wc-k  on  a  seriee  of  units. 
Permits  work  on  individual  units  in  any 

order. 

Attributes  of  the  first  unit  will  (■-- 
copied  into  every  unit  of  the  specified 
s'  rence. 


1  User  has  selected  the  first  option. 

ENTER  FIRST  AND  LAST  UNIT  NC6. 

(INFO=0,0) 

17  36  The  user  has  selected  the  sequence  from 

unit  17  to  unit  36  for  editing. 


STATUS  CF  OPTIONS: 
(l=Change,  0=Stay  Same) 

1.  Wpns  alive  =  1 

2.  wjpns  short  =  1 

3.  Wpn  type  =  1 


The  STATUS  menu  displays  the  available 
options  and  their  normal  settinq  (0  or  1) 
The  user  can  chanqe  the  settinq  of  any 
option  by  entering  its  number.  The 
information  message  will  provide  an 
explanation  of  each  option  listed. 


10.  Auto  save  =  1 

11.  New  demand  =  1 
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PROGRAM  MESSAGES 
AND  USER  RESPONSES 


COMEOTS 


TO  ALTER  STATUS  ENTER  ITEM  NO. 
(0=None;  Info=99) 


10 


0 


FOR  WPN  NO  1  GF  UNIT  17, 
ENTER  THE  FOLLOWING: 

THE  WPN  SYSTEM  NUMBER  IS: 
(INFO  99) 

9 

NO.  GF  WPNS  ALIVE  PER  Cl: 
(NCNE=0;  INF 0=99.  .) 

99  0  0 


This  entry  will  cause  the  auto  save  option 
(10)  to  be  reset  to  0.  Thus,  rather  than 
have  the  unit  values  written  directly  into 
the  file  automatically,  the  user  will  be 
polled  [SAVE? (l=yes) ]  following  each  unit. 

This  entry  designates  the  end  of  status 
changes. 

The  options  set  up  for  the  unit  sequence 
17-36  will  now  be  polled,  one  weapon  and 
one  unit  at  a  time. 


The  information  response  will  list  the 
weapon  systems  available. 

(9)  is  the  number  of  the  15Snm  howitzer. 

Pronpts  specifying  responses  "per  Cl" 
require  one  separate  entry  for  each  Cl. 

This  entry  causes  the  following  message  to 
be  listed. 


Wpns  alive  are  to  be  entered  for 
each  Cl  separately.  To  zero  out 
the  remainder  of  a  unit  for  the 
entire  phase  (all  CIs  involved) 
user  must  enter  9999  as  1st  entry 
and  any  nos.  for  remaining  entries.. 

879  Eight  weapoas  alive  are  assigned  for  the 

first  Cl,  seven  for  the  second  and  9  for 
the  third. 


NO.  CF  WPNS  RECEIVING  ANMO 
PER  Cl: 


For  artillery  weapons  only,  more  weapons 
can  receive  anmunition  than  are  listed  as 
al ive. 


8  9  12 
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PROGRAM  MESSAGES 
AND  USER  RESPONSES 


COW  ENTS 


CURRENT  DEMAND  FACTORS: 

1.  MCPP=100 

2.  INTENSITY=1 

3.  PHASE=1 

4.  NEW  EETS=0 

ENTER  FACTOR  AND  NEW  VALUE 
( NCNE=0 ,  0 ;  I  NFO= )  ,  FACTOR) 


The  demand  f actors  (1,  2,  4)  can  vary  fr<m 
unit  to  unit.  The  current  values  ar^ 
displayed  before  generatinq  the  demand  for 
the  first  weapon  of  each  unit  or  coov. 

Values  will  remain  at  their  last  setting 
until  changed. 


2  2 


Intensity  is  set  to  2  and  will  remain  equal 
to  2  until  a  new  value  is  entered. 


0,4  This  entry  will  cause  the  information 

message  for  factor  no.  4  to  be  listed: 

New  rets  shows  if  war  reserves 
or  mnt  rets  have  already  been 
entered  (0=no;  4=yes) .  If  more 
returns  are  desired,  user  enters 
one  of  the  following:  l=war; 

2==mnt;  3=both) . 


4,2 


The  program  is  set  to  prompt  for 
maintenance  returns. 


0,0 


No  more  chanoes  will  he  made. 


EMER  THE  NO.  CF  MNT  RETS  PER  Cl:  This  prompt  is  in  response  to  demand 

factor  4. 


4,5,0  The  demand  generated  will  have  4  mnt  loads 

added  in  the  first  Cl,  5  mnt  loads  added  in 
the  second  Cl,  and  none  added  in  the  third. 

New  demand  for  this  weapon  is  generated  at 
this  point. 

Following  the  completion  of  one  weapon  for 
non-artiliery  units,  the  proqram  will 
query,  NXT  WPN?(l=yesl.  If  yes,  the 
program  will  return  to  "FCR  ”PN  NO.  2  OF 
UNIT  17,  ENTER  THE  FOLLOW ,NG , "  and  continue 
until  the  unit  is  filled  or  user 
responds,  "no".  For  howitzer  unit''  the 
array  is  filled  by  the  first  entry  and 
demand  generated  for  the  entire  unit  at  one 
time. 


21 


* 


PROGRAM  MESSAGES 
AND  USER  RESPONSES 


COMMENTS 


FA  12  ACR  4  7  8  0  140  .  .  . 

5  7  8  0  564  .  .  . 

11  7  8  0  95  .  .  . 

12  7  8  0  35  .  .  . 

13  7  8  0  35  .  .  . 

0  0  0  0  0  .  .  . 

LIST  THE  UNIT  STATS?  (1=YES) 


9 


SAVE?  ( 1=YES) 


1 


WHAT  NEXT?  (INFOO) 
l=£ontinue  method 
2=Change  method 
3=Copy  units 
4=New  run 

5=Print  modified  file 
6=End 


6 

THE  PROGRAM  IS  NOW  FINISHED. 
^RETAIN 

gSYM,U  LCGRPT01 
0SYM,U  LQGRPT02 
gSYM,U  LQGRPT03 


When  a  unit  has  been  conpleted  the  results 
are  displayed. 


The  unit  statistics  contain  data  which  will 
not  be  saved,  such  as  the  no.  of  returns, 
the  phase  level  and  the  intensity. 

Unit  statistics  will  not  be  listed. 

Because  the  automatic  save  option  was 
reset,  the  program  now  prompts  the  user. 

The  data  generated  is  then  written  into  the 
file.  For  artillery  units,  the  save  routine 
will  automatically  set  the  weapons  short 
column  equal  to  weapons  alive  column  as  is 
required  by  the  ARM  model. 

The  program  will  now  fetch  the  next  unit  in 
the  sequence  and  return  to  the  prompt ,  "FOR 
WFN  1  OF  UNIT  18..."  This  process  will 
repeat  until  the  last  unit  in  the  sequence 
has  been  completed  or  the  user  has  escaped 
by  entering  9999  as  the  first  wpn  alive. 

The  program  will  now  prompt  the  user  for 
his  next  action. 


User  has  elected  to  end  the  program  run. 


User  now  frees  the  files. 

The  reports  are  now  placed  in  line  to  be 
printed  at  the  assigned  printer. 


5.  DATA  BASE  DEVELCPMEOT. 

a.  Overview.  Prior  to  processing  a  series  of  CIs  throuqh  ARM,  several 
steps  are  necessary.  One  of  these  is  the  preparation  of  the  demand  input, 
presented  in  Chapter  4.  It  is  the  purpose  of  this  chapter  to  address  the 
remaining  steps.  Therefore,  this  chapter  will  include  the  presentation  of  a 
data  base  description  or  dictionary;  the  establishment  of  an  initial  &PM  base; 
instructions  for  building  and  modifying  the  main  ARM  data  base;  and 
instructions  for  building  and  editing  event  and  distance  files. 

b.  Data  Base  Description.  Within  the  ARM  package  is  a  non-execut.ab.le 
subroutine  called  INFORM.  It  consists  of  a  brief  description  of  the  arravs 
and  variables  which  comprise  the  ARM  data  base.  The  following  is  based  uoon 
that  information.  Instructions  establishing  the  data  values  and  for  building 
and  editing  these  files  on  the  computer  are  given  in  paragraph  Sc  and  5d  of 
this  chapter.  The  ARM  user  will  have  to  become  familiar  with  these  file.;  and 
establish  the  data  values.  Sample  values  as  well  as  their  sources  for  a 
European  Heavy  Division  86  are  given  in  Volume  III. 

(1)  Unit  Data.  Following  are  the  unit  data  arrays.  In  ARM  mats  ire 
generally  played  at  the  battery  level  for  artillery  and  at  the  battalion 
for  maneuver  units.  The  arrays  or  variables  which  must  be  addressed  ;>y  the 
user  are  flagged  with  an  asterisl  (*) . 

(a)  *IUNIT  (75,142)  -  Up  to  75  ammo  using  units  of  142  words  each.  Mom 
of  the  words  or  attributes  are  used  to  describe  the  up  to  ten  types  of 
ammunition  a  unit  might  use. 

Word  Description 

1  Unit  type  (Eight  types  of  units,  explained  following  I •  tnt t 
description) . 

2  Servicing  ATP  of  the  unit. 

3  Servicing  ASP  of  the  unit. 

4  Distance  from  the  combat  trains  or  assembly  area  to  ATP  (KM) . 

5  Distance  from  the  combat  trains  or  assembly  area  to  ASP  (KM) . 

6  Time  the  last  truck  was  interdicted  for  this  unit. 

7  Helicopter  missions  received  by  the  unit  this  CT. 

8  First  ammo  type.  The  20  types  are  listed  at  5b(5) (a). 

9  Number  of  weapons  alive,  first  ammo  type. 

10  Number  weapons  short  anmo,  first  anmo  type. 

11  Number  rounds  short-all  weapons,  first  ammo  type. 

12  Current  anmo  supply-all  weapons,  first  ammo  type.  (Basic  load  on 

the  weapons  alive  minus  the  rounds  short) . 

13  Routine  supply  level-per  weapon,  first  anmo  type.  (75*  of  basic 
load  ammo  level-word  15,  the  level  of  ammunition  stockage  on  the 
weapon  at  which  resupply  would  be  initiated  given  an  oqoortunitv 
to  resupply) . 

14  Critical  resupply  level-per  weapon,  first  anmo  type.  (level  of 
ammunition  stockage  on  the  weapon  at  which  resupply  must  be 
initiated  in  order  to  sustain  firing) . 
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Basic  ammo  level-per  weapon,  first  anmo  type.  (Stockage  of  ammo 
on  the  weapon  system  itself  and/or  the  tracked  carrier 
associated  with  an  artillery  tube) . 

16  Ammo  on  trucks,  first  ammo  type.  (Lists  the  number  of  rounds 
bulk  loaded  on  the  unit  ammo  trucks.  It  represents  the  bulk 
loaded  portion  of  the  true  basic  load) . 

17  Number  of  weapons  killed  at  the  end  of  Cl,  first  ammo  type. 

{Input  from  the  Wargame  each  Cl  and  is  used  to  reduce  the 
original  number  of  weapon  systems  alive). 

18  Number  of  weapons  short  ammo,  first  ammo  type.  (Used  to 
determine  the  reload  requirements  per  weapon  based  upon  total 
rounds  short) . 

19  Total  rounds  demanded  through  whole  Cl,  first  arrmo  type.  (Input 
from  the  Wargame  each  Cl  and  is  used  as  the  demand  on  the 
resupply  network) . 

20  Storage  for  number  of  rounds  resupply  in  route,  first  ammo 
type.  (Attributes  21-137  describe  the  up  to  nine  other  types  of 
anmo  used  by  a  unit.  In  describing  a  MLRS  unit,  for  exanple 
only  one  type  of  ammo  is  fired  so  only  attributes  8-19  are  used). 

21-33  As  above,  for  second  ammo  type,  in  attributes  8-20. 

34-46  As  above,  for  third  ammo  type. 

47-59  As  above,  for  fourth  anmo  type. 

60-72  As  above,  for  fifth  arrmo  type. 

73-85  As  above,  for  sixth  anmo  type,  (currently  not  used) 

86-98  As  above,  for  seventh  ammo  type,  (currently  not  used) 

99-111  As  above,  for  eighth  arrmo  type,  (currently  not  used) 

112-124  As  above,  for  ninth  ammo  type,  (currently  not  used) 

125-137  As  above,  for  tenth  ammo  type,  (currently  not  used) 

138  Number  of  helicopters  missions  assigned.  (Only  for  155.nm 
units.  Used  to  determine  whether  or  not  a  unit  has  received  its 
maximum  number  of  helicopter  resupply  missions  this  Cl) . 

139  =  0,  if  single  pulse  demand  per  Cl.  (If  reload  of  rounds  fired 
is  aoconplished  once  during  the  Cl) . 

=  1,  if  multiple  pulse  demand  per  Cl.  (For  artillery  units  the 
total  Cl  demand  is  divided  by  the  number  of  hours  in  the  Cl  and 
that  amount  is  resupplied  each  hour  of  the  Cl) . 

140-142  Counters.  (Conputed  and  used  internal  to  AFM  program) . 

(b)  Explanation  of  unit  type  codes,  word  1  of  IUNIT. 


Code  Unit  Type 

1  Tank  Task  Force. 

2  Mechanized  Task  Force. 

3  Armored  Cavalry  Squadron. 

4  155  Artillery  Battery. 

5  8-inch  Artillery  Battery. 

6  MLRS  Battery. 

7  DIVAD  Gun  Platoon. 

8  Combat  Aviation  Platoon. 
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(c)  AUNIT  (75,2)  -  75  units,  2  alpha  fields  per  unit.  Word  1  is  usual 
left  blank  as  the  computer  does  nothing  with  it  and  it  might  cause 
classification  problems. 

Word  Description 

1  LflM  coordinates.  (Identifies  unit  map  position) . 

2  Alpha  unit  names.  (Unit  name  as  it  appears  in  wargame) . 

(d)  Explanation  of  MLRS  queue  server  counters.  These  counters  are  used 
by  the  program  and  are  not  entered  by  the  operator.  They  refer  to  the  number 
of  MLRS  that  can  be  reloading  at  a  supply  point  at  any  one  time  (a  maximum  of 
three) . 

Server 

Counter  Description 

1  Number  of  failures. 

2  Number  of  S&P  offloads. 

3  Number  of  ASP-ATP  S&P  load  ups. 

4  Number  of  5  ton  load  ups. 

5  Number  of  10  ton  load  ups. 

6  Number  of  load  ups  from  CSA  S&Ps. 

7-8  Not  used. 

(2)  Truck  Data. 

(a)  *ITRUCK  (1400,15)  -  For  all  vehicles,  1400  trucks  with  15  words  each 
as  follows: 


Word  Description 

1  Truck  type  (Explained  following  truck  arrays) . 

2  Mission  type  (Explained  following  truck  arrays) . 

3  Status  type  (Explained  following  truck  arrays) . 

4  Owner  number.  (The  ARM  number  identifying  a  particular  unit). 

5  Ammo  mix  number//Server  off-load  time  at  ASP.  (The  number  tha! 
identifies  the  types  of  ammo  hauled  by  the  truck.  Defined  in 

I MIX,  section  5b (5) (b) ) . 

6  Percent  loaded//Server  load  time.  (Percent  of  airmo  load  on  truck 
at  a  given  point  in  time  -  not  usually  entered  except  initially, 
calculated  by  program) . 

7  Time  since  last  failure  (MIN) .  (Used  to  determine  the  time  the 
truck  will  break  down  by  subtracting  from  it  all  subsequent 
movement  times.  Established  for  all  trucks  at  the  beginning  of 
the  game  by  multiplying  MTBF  for  each  type  truck  by  a  random 
number  from  0-1) . 

(8-15  are  general  truck  counters  concerning  unit,  CSA-ATP,  CSA-ASP, 
ASP-ATP.  They  are  used  by  the  program  and  not  addressed  by  the  user) . 


Truck  Counters:  UNIT  CSA- ATP  CSA-ASP  AST- ATP 

81#  failures. 

92#  interdictions. 

10  3  #  Arrivals  from:  ASP/ATP  Reloads  CSA  CSA  ASP  Thru-outs 

11  4  #at  CSA  #  at  CSA  at  ASP 

12  5  Queue  time.  ASP/ATP  Bnpd  CSA  CSA  At  ASP  (MIN) 

13  6  To  2d  ASP  Time  Mt  in  ATP/ASPQ 

14  7  Bnpd  to  ASP  #  Empty  @  ASP  Bmpd  to  rear 

15  8  .GT.  3  in  MLRS  Q  ASP 

(b)  Explanation  of  truck  type  codes. 


1  10  ton. 

2  5  ton. 

3  5  ton  with  a  1  1/2  ton  trailer. 

4  10  ton  with  a  10  ton  trailer  (MLRS) . 

5  22  ton  S&P. 

6  Helicopter. 

7  Goer. 

8  Rough  terrain  forklift. 

9  Crane. 


(c)  Explanation  of  truck  mission  type  codes. 

Code  Mission 

1  Unit  truck. 

2  CSA- ATP  link. 

3  CSA-ASP  link. 

4  ASP- ATP  link. 

5  ASP-unit  (helicopter) . 

6  ATP  server. 

7  ASP  server. 

8  Not  used. 

9  Bumped  to  rear  of  system  ASP. 

(d)  Explanation  of  truck  status  type  codes. 

Code  Truck  Status 

1  In  unit  queue  -  or  available  if  truck  is  acting  as  server. 

2  In  ATP  queue. 

3  In  ASP  queue. 

4  In  transit  -  or  busy  if  truck  is  acting  as  server. 

5  Unit  truck  going  from  ATP  to  ASP  -  server  moving  to  new  location. 

6  Truck  awaiting  repair. 

7  Truck  dead  (interdicted). 

8  In  CSA  queue. 

9  Bumped  to  2d  ASP  -  server  of  interdicted  ASP/ATP. 
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(e)  *1TYPE{9,6)  -  speed  and  maintenance  data  for  vehicles.  9  truck 
types,  6  words  for  each  type,  as  follows: 

Word  De script  ion 

1  Secondary  road  niqht  speed  (unit  to  ASP,  ATP)  (KM/hp j . 

2  Secondary  road  day  speed  (unit  to  ASP,  ATP). 

3  Highway  night  speed  (KM/HR) .  (CSA-ASP) . 

4  Highway  day  speed  (KM/HR) .  (CSA-ASP) . 

5  MTBF  (MIN) .  (Mean  tine  before  failure) . 

6  WITR  (MIN) .  (Mean  time  to  repair) . 

(f)  Queue  list.  Truck  queues  1-176  are  described  as  follows: 


Truck  Queue 

Queue  Type 

Description 

1-75 

1 

At 

each 

unit. 

76-85 

2 

At 

ATPs 

for 

CSA- ATP  S&Ps. 

86-95 

3 

At 

ATPs 

for 

ASP- ATP  S&Ps. 

96-105 

4 

At 

ATPs 

for 

unit  artillery  server. 

106-115 

5 

At 

ATPs 

for 

unit  maneuver  server. 

116-125 

6 

At 

ATPs 

for 

servers. 

126-135 

7 

At 

ASPs 

for 

CSA-ASP  S&Ps. 

136-145 

8 

At 

ASPs 

for 

routine  unit  trucks. 

146-155 

9 

At 

ASPs 

for 

MLRS  unit  trucks. 

156-165 

10 

At 

ASPs 

for 

servers. 

166-175 

11 

At 

ASPs 

for 

ASP- ATP  S&Ps. 

176 

12 

At 

CSA 

for  CSA  S&Ps. 

(3)  ATP  Data. 

(a)  *IATP  (10,53)  -  General  ATP  data  for  10  ATPs,  53  words  each  as 
follows : 

Word 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 
13 


Description 

Distance  to  CSA  (KM) . 

Distance  to  ASP  (KM) . 

Distance  to  DAO  (KM) . 

Not  used. 

Number  of  arriving  S&P  tractors  used  for  return  of  empty 
trailers. 

Associated  ASP  number. 

Queue  for  ASP  S&P.  (Explained  at  5b(2)(f),  Queue  list). 

Number  of  MLRS  trucks  being  served. 

Queue  for  CSA  S&P.  (Explained  at  5b (2) (f)). 

Server’s  queue  number.  (Explained  at  5b(2)(f)). 

Artillery  queue  number.  (Explained  at  5b (2) (f)). 

Maneuver  unit  queue  number.  (Explained  at  5b (2) (f)) . 

Convoy  counter  at  CSA  (If  greater  than  or  equal  to  3,  schedules 
convoy  forward) . 
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Word 

De script  ion 

14 

Number  of  trucks  in  artillery  queue. 

15 

Number  of  trucks  in  maneuver  unit  queue.  (Explained 

5b  (2) (f))  . 

16 

Server  removal  counter. 

17 

Number  of  convoys 

sent  from  CSA. 

18-19 

Not  used. 

20 

Number  of  times  a 

server  is  not  available. 

21 

Current  ammo  supply,  ammo  number  1. 

22 

Queue  ammo  demand, 

ammo  number  1. 

23 

Ammo  on-the-way  (from  DAO),  ammo  number  1. 

24-26 

Same  as  21-23,  for 

aimo  number  2 

27-29 

arrmo  number  3 

30-32 

aimo  number  4 

33-35 

ammo  number  5 

36-38 

airmo  number  6 

39-41 

ammo  number  7 

42-44 

arrmo  number  8 

45-47 

ammo  number  9 

48-50 

ammo  number  10 

51 

fuzes 

52-53 

Not  used. 

(b) 

*IATPSD  (5)  -  ATP  service  data,  5  words  as  follows: 

Word 

Descr iption 

1  Lowest  ASP-ATP  round-robin  S&P  number. 

2  ATP  first  priority  S&P  queue. 

3  ATP  2d  priority  S&P  queue. 

4  CFA  ATP  owner  number. 

5  Not  used. 

(c)  IATPSP  (10,22)  -  Used  to  obtain  ASP  %  replenishment,  10  ATPs  with  22 
words  each,  as  follows: 


Word  Description 

1-11  Number  of  CSA  S&Ps  arriving,  by  aitmo  type. 

12-22  Number  of  ASP  S&Ps  arriving,  by  ammo  type. 


(d)  I ATP  AM  (10,40)  -  Ammo  removed  from  ATP  for  10  ATPs  and  10  amro  types, 
as  follows: 


Description 


I- 10  Number  of  10  ton  trucks  serviced  (MLRS  with  trailer) . 

II- 20  Number  of  5  ton  trucks  serviced  (MLRS  without  trailer) . 

21-30  Number  of  10  ton  trucks  bunped. 

31-40  Number  of  5  ton  trucks  bumped. 
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(e)  JATP  (10,6)  -  For  the  10  A TPs 


as  fol  Iowa: 


Word  Descr  iption 

1  Number  of  trucks  served  by  the  maneuver  queua. 

2  Total  queue  wait  time  for  all  -.rucks  served  (MIN). 

3  Maximum  wait  time  lor  the  maneuver  queue  (MIN). 

4  Trucks  served  through  the  artillery  queue. 

5  Total  queue  wait  time  for  all  queues  served  (MIN) . 

6  Maximum  wait  time  for  the  art.i  llerv  queue  (MIN)  . 

(4)  ASP  Data. 

(a)  *1ASP  (10,110)  -  This  genera]  ASP  data  concerns  10  ASPs  described  by 
110  words  each  as  follows: 

Word  Description 

1  Distance  to  CSA  (KM) . 

2  ASP  status  (-1  inactive,  0  active/no  convoys,  1  active/'convoys)  . 

3  Cumulative  helicooter  counter. 

4  Queue  for  CSA -ASP  S&P  trucks.  (Explained  at  5b(2)  (fV)  . 

5  Number  of  trucks  to  CSA. 

6  Number  of  empty  S&Ps  at  ASP. 

7  Server's  queue  numoer.  (Explained  at  5b  (2)  (f )  > . 

8  Number  of  MLRS  being  served. 

9  Routine  queue  number.  (Explained  at  5b(2)(f)). 

10  MLRS  queue  number.  (Explained  at  5b(2)(f>). 

11  Rear  ASP  number. 

12  Number  of  trucks  in  routine  queue. 

13  Number  of  trucks  in  MLRS  queue. 

14  Convoy  counter  at  CSA  (If  greater  than  or  eaual  to  7,  schedule 

convoy  forward) . 

15  Helicopter  server  counter. 

16  Server  removal  counter. 

17  Number  of  convoy  sent  from  CSA. 

18  Queue  for  ASP-ATP  round-robin  S&Ps.  (Explained  at  5b (2) (f)). 

19  Not  used. 

20  Number  of  times  a  server  is  not  available  for  a  unit  truck. 

21  Current  ammo  supply,  ammo  number  1. 

22  Queue  anmo  danand,  ammo  number  1. 

23  Ammo  on-the-way  (from  CSA  or  DAO)  ,  ammo  number  1. 

24-110  Same  as  words  21-23  for  ammo  2-30. 

(b)  IASPSP  (10,30)  -  Used  to  store  S&P  arrivals  by  ammo  type,  for  10  ASPs 
and  30  anmo  types. 
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(c)  JASP(10,9)  -  For  the  10  ASPs,  as  follows: 

Word  Description 

1  Trucks  served  through  the  routine  queue. 

2  Total  wait  time  for  all  trucks  served  (MIN) . 

3  Maximum  wait  time  in  the  routine  queue  (MIN) . 

4  Trucks  served  through  the  MLRS  queue. 

5  Total  wait  time  for  all  trucks  served  (MIN) . 

6  Maximum  wait  time  in  the  MLRS  queue  (MIN) . 

7  Trucks  served  through  the  ASP- ATP  queue. 

8  Total  wait  time  for  all  trucks  served  (MIN) . 

9  Maximum  wait  time  in  the  ASP-ATP  queue  (MIN) . 

(d)  IASPAM  (10,  120)  -  Aireno  removed  from  ASP  for  10  ASPs  and  30  ammo 
types,  as  follows: 

Word  Description 

1-30  Number  of  10  ton  trucks  serviced. 

31-60  Number  of  5  ton  trucks  serviced. 

61-70  Number  of  ATP  S&Ps  serviced. 

71-80  Number  of  CSA-ATP  arrivals. 

90  Number  of  helicopter  loads  removed. 

91-120  Number  of  CSA-ASP  S&Ps  arrived. 

(e)  *IAMLVL(2,30)  -  stockage  level  objectives  for  up  to  10  ATPs  and  30 
ASPs,  as  follows: 

Word  Description 

1.1- 28  ATP  stockage  objectives. 

2.1- 30  ASP  stockage  objectives. 

1.29  Maximum  ATP  stockage  %. 

1.30  Maximum  ASP  stockage  %. 

(f)  *ISERV(10)  -  Used  for  server  manipulations,  as  follows: 

Word  Description 

1  Number  of  ATP  servers  to  be  held  (As  for  displacement  -  all 
ATPs) . 

2  Number  of  ASP  servers  to  be  held  (As  for  displacement  -  all 
ASPs) . 

3  ATP  server  hold  queue. 

4  ASP  server  hold  queue. 

5  Number  of  interdicted  ATP. 

6  Number  of  interdicted  ASP. 

7  Minutes  servers  to  be  held  in  hold  queue  at  ATP. 

8  Minutes  servers  to  be  held  in  hold  queue  at  ASP. 

9-10  Not  used. 
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(5)  Ammo  Data. 


(a)  Ammo  type  codes  -  the  20  ammo  ty|x?  code--  are  as  follows: 

Code  Descr  ipt  ion 

1  105mm  (M60-A3/XM1) . 

2  TOW. 

3  Powder  canisters.  (For  155mm  FA) . 

4  155mm  HE. 

5  155mm  ICMDP. 

6  8- inch  HE. 

7  8- inch  ICMDP. 

8  8-inch  powder. 

9  Hellfire. 

10  MLRS. 

11  155mm  RAP. 

12  155mm  CLGF. 

13  155mm  smoke. 

14  30mm  (AAH) . 

15  8- inch  RAP. 

16  Mortar. 

17  Bashmaster. 

18  DIVAD. 

19  Small  arms. 

20  Fuzes. 

(b)  *IMIX (91, 32)  -  Ammo  mix  quantities  and  load  times.  91  anmo  mixes 
(1-30,  10-tori  mixes;  31-60,  5-ton  mixes;  61-90,  S&P  mixes;  91,  helicopter 
mixes),  32  words  for  each  mix.  For  each  of  up  to  30  anmo  codes  used  in  ARM 
this  file  contains  one  or  more  mix  numbers.  Each  mix  number  represents  the 
number  of  rounds  of  that  type  ammmtion  that  can  be  hauled  on  a  particular 
truck  type.  Attributes  31  and  32  provide  the  load  time  for  this  quantity  of 
rounds  at  the  ATP  and  ASP,  respectively. 


Word 

Descript  ion 

1-30 

Number  of  rounds 

of  each  ammo 

31 

Load  time  at  CSA/ATP  (MIN) . 

32 

Load  time  at  ASP 

(MIN) . 

(6) 

Miscellaneous  Data. 

(a) 

Event  scheduling. 

C<M4CN/EVENrS/JSTAT (6) ,  JEVDS (2048,4) ,  IEVS(5,2048)  -  These 
arrays  are  used  in  ARM  to  perform  internal  bookkeeping  type  functions. 

(b)  Queue  data. 
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CCMMCN/QUENUM/IHFAD(176)  -  Head  of  truck  queue. 
CCMMCN/QUEPNT/ITFMS (1400)  -  Trucks  in  queue. 


(c)  Interdiction  data. 

COMCN  *INTER(10) 

Word  Description 

1  Counter  for  zone  1  trucks  killed  in  INTRDK. 

2  Counter  for  zone  2  trucks  killed  in  INTRDK. 

3  Number  of  trucks  to  be  killed  in  zone  1. 

4  Number  of  trucks  to  be  killed  in  zone  2. 

5  Time  to  replace  truck  in  zone  1. 

6  Time  to  replace  truck  in  zone  2. 

7  Modulo  of  trucks  to  be  killed  in  zone  1. 

8  Modulo  of  trucks  to  be  killed  in  zone  2. 

9  Number  of  zone  1  truc<s  entering  INTRDK. 

10  Number  of  zone  2  trucks  entering  INTRDK. 

(d)  *IDAY 

1  =  Day,  0  -  Night 

(e)  ICSA(3,32)  -  Number  of  rounds  from  CSA  by  ammo  type,  as  follows: 

(1,1-11)  Number  of  S&Ps  to  ATP. 

(2,1-30)  Number  of  S&Ps  to  ASP. 

(3,1-30)  Cumulative  ammo  demand  of  all  units. 

(1.30)  Ammo  types. 

(2.31)  Counter  for  empty  S&Ps  at  CSA. 

(3.32)  Counter  for  empty  PCL  trucks  at  CSA. 

(f)  *LPPAR(8)  -  System  parameters.  Values  in  parentheses  may  be  varied 
depending  upon  scenario,  though  some  program  modification  might  be  recruired. 

Description 

Total  number  of  ammo  codes  (20).  (Maximum  number  at  an  ASP). 
Number  of  ammo  codes  at  ATP  (10) . 

Number  of  maneuver  unit  ammo  codes  at  ATP  (3) . 

Number  of  transports  (trucks)  (Less  than  1400). 

Number  of  helicopters  available  (10). 

Number  of  ammo  types  at  units  (Less  than  or  equal  to  10) . 
Number  to  subtract  from  5-ton  mix  to  get  ammo  type.  (20) . 
Number  to  subtract  from  S&P  mix  to  get  ammo  type.  (60). 


Word 

1 

2 

3 

4 

5 

6 

7 

8 
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(g)  *TCIST  -  Time  of  start  of  Cl  in  decimal  minutes  (TCI ST"  must  be  .000 
for  CI01) . 

(h)  *TCILNR  -  Time  length  of  Cl  in  decimal  minutes. 

(i)  *TIME  -  Current  simulation  time  in  decimal  minutes. 

(j)  *LUQJT  -  Refers  to  the  unit  number  c.f  where  the  ARM  audit  traj  j  in 
being  written.  Should  be  set  and  left  at  value  of  "2".  Transfers  output  to 
file  which  can  then  be  printed  out. 

(k)  JUNIT(8,24)  -  Truck  data  for  8  unit  types,  as  follows: 

Word  Description 

1  Number  of  trucks  sent  to  the  ATP  from  the  unit. 

2  Number  of  trucks  killed  on  that  move. 

3  Number  of  trucks  failed  on  that  move. 

4  Total  travel  time  for  all  trucks  on  that  move. 

5  Number  of  trucks  sent  to  the  ASP  from  the  unit. 

6  Number  of  trucks  killed  on  that  move. 

7  Number  of  trucks  failed  on  that  move. 

8  Total  travel  time  for  all  trucks  on  that  move  (MIN) . 

9  Number  of  trucks  sent  to  the  ASP  from  the  ATP. 

10  Number  killed  on  that  move. 

11  Number  failed  on  that  move. 

12  Total  travel  time  for  all  trucks  on  that  move.  (MINI . 

13  Number  of  trucks  sent  to  the  unit  from  the  ATP. 

14  Number  killed  on  that  move. 

15  Number  failed  on  that  move. 

16  Total  travel  time  for  all  trucks  on  that  move  (MIN) . 

17  Number  of  trucks  sent  to  the  unit  from  the  ASP. 

18  Not  used. 

19  Number  failed  on  that  move. 

20  Total  travel  time  for  all  trucks  on  that  move  (MIN) . 

21  Total  time  spent  in  reloading  weapons  (MIN) . 

22  Total  time  available  for  unit  trucks  (MIN) . 

23  Number  of  trucks  killed  during  reload. 

24  Not  used. 

1)  *IRSTME(23,3)  -  Resupply  time  data  for  23  ammo  types,  3  words  each, 

follows: 

Word  Description 

1  Weapon  set-up  time  (MIN) .  (Time  it  takes  a  weapon  system  to  he 

prepared  to  take  on  ammo  once  the  ammo  truck  arrives  in  the  area  of 
the  weapon) . 
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2  Load  time  per  round  (MIN/1000) .  (The  average  time  it  takes  to  uncase 
a  round  and  store  it  on  the  weapon  system) . 

3  Travel  time  to  weapon  (MIN) .  (Che-way  travel  time  from  the  truck 
assembly  area  or  combat  trains  to  the  weapon  system.  It  is  corrouted 
based  on  the  approximate  distance  that  the  trucks  are  likely  to  be 
from  the  weapon  systems  they  support  and  the  travel  speed  of  the 
truck.  Travel  speed  is  calculated  as  the  average  speed  for  50%  cross 
country  and  50%  secondary  roads. 

(m)  Event  Types  -  The  19  ARM  events,  their  5  parameters,  and  their 
descriptions  are:  (Note  -  parameter  5  is  also  the  event  type  number) 


EVENT 

(1) 

(2) 

(3) 

(4)  (5) 

DESCRIPTION 

DEMAND 

UNIT  # 

1 

Checks  ammo  demand 
of  units 

RELOAD 

UNIT  # 

TK  # 

2 

Replaces  rds  of 
armto  at  unit  wpns 

UNTDEP 

UNIT  # 

TK  f 

3 

Departure  of  TO 
from  unit 

ATPARV 

UNIT  # 

TK  # 

ATP  # 

4 

Arr  or  unit  TO  at 

ATP 

ASPARV 

UNIT  # 

TK  # 

ASP  # 

mix 

5 

Arr  of  unit  TO  at 

ASP 

ATP 

1=ARTY  Q 
2=MAN  Q 

ATP  # 

TK  # 

SVR  # 

6 

Svc  of  TO  from  0  at 
ATP 

ASP 

l=Routine 

Q 

2=MLRS  Q 

ASP  # 

TK  # 

SVR  # 

7 

Svc  of  TO  from  ASP  0 

UNEARV 

UNIT  # 

TK  # 

8 

Arr  of  TK  at  unit 

CSAARV 

ATP/ASP  # 

S&P  # 

ASP  t 

0  -  ATP 

1  -  ASP 

9 

Arr  of  S&P  at  CSA 

ATPAR1 

ATP  t 

S&P  # 

ASP  # 

0/555  - 
rtn  from 
reload 

10 

Arr  of  S&P  from  CSA 

ATPAR2 

ATP  # 

S&P  # 

ASP  # 

0/55 

rtn  from 
reload 

11 

Arr  of  S&P  from  ASP 

ASPAR1 

ATP  # 

S&P  # 

ASP  ? 

12 

Arr  of  ASP  S&D  at 

ASP  (from  ATP) 
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nESCKfPTiU. 


EVENT 

U 1 

(-} 

(  s\ 

(4) 

(5) 

nESCKfPfjfi 

ASPAR2 

ASP  # 

S&P  # 

13 

Arr  of  Sf.'  VF  at 

ASP  from  CSA 

HELARV 

UNIT  # 

HF.L.T  # 

1* 

A  r  .'f  :  ;  d  u’i j  t 

HAS PAR 

None 

HFL I  # 

15 

Arr  of  [:<■/]  i  ,f  •  -k  at 

ASP 

CSADEP 

ATP/ASP  # 

S&P  # 

16 

Departure  of  S&P  to 
ASP/ATP 

REPORT 

17 

Writes  leic. 

CCNTRCL 

8888 

8888 

8888 

8888 

18 

ENDSIM 

9999 

‘•999 

9999 

9999 

19 

c.  Establishing  the  Initial  ARM  Data  Base.  Taking  an  initial  ia'-..  base 
such  as  that  shown  in  Vol  ITT,  a  data  base  for  any  scenario  can  he-  established 
by  applying  suitable  modifications  to  it.  This  requires  changes  to  be  *x>  1 ied 

to  all  or  some  of  the  values  appearmq  in  the  arrays/variables:  I  ATP,  I  ASP, 

I  UNIT,  I  TRUCK,  I  TYPE,  IM1X,  1  AMI,  VI. ,  IATPSD,  IDAY,  1CIST,  TCLNG,  TTMF .  iUCTjr, 
IRSTME,  I MIX,  INTER,  I.PPAR,  and  ISERV.  These  arrays/variables  will  re 
addressed  now  in  the  order  they  appear  on  the  data  base  printout.  Vine re  the 
numbers  are  derived  and  in  some  cases  what  the  numbers  should  be  will  N? 
discussed,  but  the  main  emphasis  will  be  on  the  general  source  of  where  the 
numbers  come  from.  A  fuller  discussion  of  outside  data  sources  will  he  found 
in  Volume  III. 

(1)  IATP  (10, 5.3) -defined  in  section  5b(3)  (a)  .  Values  for  each  of  these 
up  to  10  ATPs  used  must  be  set  for  the  53  attributes  as  follows. 

Attribute  1-3  are  the  road  distances  in  KM  to  the  CSA,  ASP,  and  DAO, 
respectively.  Positions  of  units,  CSA,  ASP,  and  DAO  are  set  in  accordance 
with  the  scenario  and  doctrine. 

Attribute  4  is  not  used. 

Attribute  5  is  the  number  of  arriving  S&P  tractors  used  for 
return  of  empty  trailers.  This  value  is  left  for  the  user  to  decide  in 
accordance  with  a  specific  scenario. 

Attribute  6  is  the  ASP  serviced  by  this  ATP.  ATPs  have  been 
numbered  from  1-10,  while  ASPs  are  numbered  from  11-14  in  this  exarrple.  This 
is  a  user  decision. 

Attribute  7  is  the  queue  for  ASP  S&P.  This  should  be  set  to  zero. 

Attribute  8  is  the  number  of  MLRS  trucks  being  served.  This 
should  be  set  to  zero. 
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Attribute  9  is  the  queue  for  CSA  S&P.  This  should  be  set  to  zero. 

Attribute  10  is  the  server's  queue  number.  These  are  assigned 
number  116-125  for  ATPs  1-10,  as  per  queue  list  5b(2) (f). 

Attribute  11  is  the  artillery  queue  number,  numbers  96-105  from 
the  queue  list. 

Attribute  12  is  the  maneuver  unit  queue  number,  numbers  106-125 
from  the  queue  list. 

Attribute  13  is  the  convoy  counter  at  CSA.  This  should  be  zero. 

Attribute  14  is  the  number  of  trucks  in  the  artillery  queue. 

This  should  be  set  to  zero. 

Attribute  15  is  the  number  of  trucks  in  the  maneuver  unit  queue. 
This  should  be  set  to  zero. 

Attribute  16  is  the  server  removal  counter.  This  should  be  set 

to  zero. 

Attribute  17  is  the  number  of  convoys  sent  from  CSA.  This  should 
be  set  to  zero. 

Attribute  18-19  are  not  used. 

Attribute  20  is  the  number  of  times  a  server  is  not  available. 
This  should  be  set  to  zero. 

Attribute  21  is  the  current  ammo  supply  of  ammo  number  1.  This 
is  the  user's  decision. 

Attribute  22  is  the  queue  ammo  demand,  ammo  number  1.  This 
should  be  set  to  zero. 

Attribute  23  is  ammo-on- the-wa/  (from  DAO)  for  anmo  number  1. 

This  should  be  set  to  zero. 

Attribute  24-26,  27-29, _ _  48-50  are  the  same  variables  as 

attributes  21-23,  but  for  ammo  number  2,  3,...,  10. 

Attribute  51  is  the  number  of  fuzes  at  the  ATP.  User's  choice. 

Attributes  52-53  are  not  used. 

(2)  I ASP  (10,110) -defined  in  section  5b(4) (a).  Values  for  each  of  the  up 
to  10  ASPs  used  should  be  set  for  the  110  attributes  as  follows: 


Attribute  1  is  the  road  distance  to  the  CSA  in  km.  Should  .'-or 
in  accordance  with  scenario  and  doctrine. 

Attribute  2  is  the  ASP  status  (=  -  1  if  inactive,  =  0  if 
active/no  convoys,  =  1  active  convoys).  Should  set  active  ASPs  to  1,  i native 
ASPs  to  -1,  0  when  desiring  to  deactivate  the  ASP . 

Attribute  1  is  the  cumulative  helicopter  counter.  Should  r,o 
zeroed  initially. 

Attribute  4  is  the  queue  for  CSA-ASP  trucks.  Should  be  set 
according  to  queue  list. 

Attribute  5  is  the  number  of  trucks  to  CSA.  Should  lx-  set  to 


Attribute  6  is  the  number  of  emnty  S&Ps  at  ASP.  Should  K-  set  to 


Attribute  7  is  the  server's  queue  number.  Should  he  sec. 
according  to  queue  list. 

Attribute  8  is  the  number  of  MLRS  heina  served.  Should  no  s'-t  to 


Attribute  9  is  the  routine  queue  nunter.  Set  according  to  queue 

list. 

Attribute  10  is  the  MLRS  queue  number.  Set  by  the  queue  list. 
Attribute  11  is  the  rear  ASP  number.  User's  decision,  baser  upon 

his  scenario. 

Attribute  12  is  the  number  of  trucks  in  the  routine  queue.  This 
should  be  set  to  zero. 

Attribute  13  is  the  number  of  trucks  in  MLRS  queue.  Set  to  ze^o. 

Attribute  14  is  the  convoy  counter  at  CSA.  Set  to  zero.. 

Attribute  15  is  the  helicopter  server  counter.  Set  to  zero 

Attribute  16  is  the  server  removal  counter.  Set  to  zero. 

Attribute  17  is  the  number  of  convoy  sent  from  CSA.  Set  to  zero. 


queue  list. 


Attribute  18  is  the  queue  for  ASP-ATP  round-robin  S&Ps.  Set-  from 
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Attribute  19  is  not  used. 

Attribute  20  is  the  number  of  times  a  server  is  not  available  for 
a  unit  truck.  Set  to  zero. 

Attribute  21  is  the  current  anmo  supply,  anrcno  number  1.  User 
sets  according  to  scenario. 

Attribute  22  is  the  queue  anmo  demand,  ammo  number  1.  Set  to 

zero. 

Attribute  23  is  the  amno-on-the-way  (from  DAO  or  CSA) ,  ammo 
number  1.  Set  to  zero. 

Attributes  24-110  are  the  same  as  attributes  21-23,  for  ammo 

types  2-30. 

(3)  I UNIT  (75,142) -defined  at  5b(l) (a).  Values  for  each  of  the  up  to  75 
units. 

Attribute  1  is  the  unit  type,  determined  from  the  unit  type 
codes,  section  5b (1) (b) . 

Attribute  2  is  the  number  of  the  unit's  serving  ATP.  Set  by  user 
from  scenario. 

Attribute  3  is  the  number  of  the  unit's  servicing  .c  .  Set  by 
user  from  scenario. 

Attributes  4-5  are  the  road  distances  in  KM  to  the  unit's  ATP  and 
ASP,  respectively.  All  positions  are  set  in  accordance  with  scenario  and 
doctrine. 


Attribute  6  is  the  time  the  last  truck  was  interdicted  for  this 
unit.  Should  be  initialized  to  zero. 

Attribute  7  is  the  helicopter  missions  received  by  the  unit  this 
Cl.  Set  to  zero. 

Attribute  8  is  the  number  of  the  first  arnno  type,  determined  from 
the  ammo  type  codes,  section  5b(5) (a). 

Attribute  9  is  the  number  of  weapons  alive  which  fire  the  first 
ammo  type  in  that  unit.  Set  according  to  scenario.  Usually  the  number  of 
tubes  firing  this  ammo  in  a  battery  or  battalion  for  maneuver  unit. 

Attribute  10  is  the  number  of  weapons  short,  first  ammo  type. 

Set  to  zero. 


Attribute  11  is  the  number  of  rounds  short  for  all  the  weapons, 
first  ammo  type.  Set  to  zero. 
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Attribute  12  is  the  current  ammo  supply  for  all  weapon';,  first 
amnto  type.  Set  to  the  total  basic  load  of  all  weapons  firing  this  amoo  in  the 
unit. 

Attribute  13  is  the  routine  resupply  level  per  weapon,  fnst  ammo 
type.  Set  to  75%  of  basic  load  for  a  weapon. 

Attribute  14  is  the  critical  resupply  level  per  weapon,  first 
ammo  type.  (Jser  may  set  according  to  doctrine  enployed.  Note  -  used  onlv  tor 
155  artillery  units,  for  other  units  set  to  zero. 

Attribute  15  is  the  basic  ammo  level  per  weapon,  first  ammo 
type.  Depends  on  weapon  type. 

Attribute  16  is  the  ammo  on  trucks,  first  ammo  type.  This  is  the 
bulk  loaded-on  trucks-portion  of  the  true  basic  load.  Depends  on  weapon  and 
truck  type. 

Attribute  17  is  the  number  of  weapons  killed  at  the  end  of  the 
Cl,  first  ammo  type.  Set  to  zero. 

Attribute  18  is  the  number  of  weapons  short  ammo,  first  ammo 
type.  Set  to  zero. 

Attribute  19  is  the  total  rounds  demanded  through  the  whole  Cl , 
first  ammo  type.  Set  to  zero. 

Attribute  20  is  the  storage  for  number  of  rounds  resupoly  in 
route,  first  ammo  type.  Set  to  zero. 

Attribute  21-137  are  the  same  as  attributes  8-20  for  anmo  types 

2-10. 

Attribute  138  is  the  number  of  helicopter  missions  assigned  for 
155mm  units  emergency  resupply.  Set  to  zero. 

Attribute  139  equals  zero  if  resupply  happens  once  per  Cl.  T\  is 
set  equal  to  one  if  resupply  is  desired  each  hour  of  the  Cl,  the  amount  beinq 
equal  to  the  demand  divided  by  the  number  of  hours  in  the  Cl.  The  "pulsed" 
demands  are  usually  used  for  artillery  and  aviation  units. 

(4)  ITRUCK  (1400,15) -defined  at  5b < 2) (a) .  The  15  attributes  for  the  up 
to  1400  trucks  should  be  filled  as  follows: 

Attribute  1  is  the  truck  type,  defined  in  section  5b(2) (b) . 

Attribute  2  is  the  mission  type,  defined  in  section  5b(2) (c) . 

Attribute  3  is  the  status  type,  defined  in  section  5b ( 2 ) (d) . 

Attribute  4  is  the  number  of  the  unit  to  which  the  truck  is 
assigned.  User  and  scenario  dependent. 
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Attribute  5  is  the  ammo  mix  number,  determined  from  TMTV  in 
section  5b (5) (b) . 

Attribute  6  is  the  percent  loaded  on  the  truck.  Should  usually 
be  set  to  10,000  initially  (which  represents  100%) . 

Attribute  7  is  the  time  since  last  failure.  Set  to  zero. 

Attribute  8-15  are  counters.  Set  to  zero. 

(5)  I MIX  (91,32) -defined  at  5b (5) (b) .  91  mixes  with  32  words  for  each 
mix.  Of  the  32  words  the  first  30  refer  to  ammo  types  1-30.  Mixes  1-30  are 
10-ton  mixes,  31-60  are  5-ton  mixes;  61-90  are  S&P  mixes;  91,  helicopter 
mixes.  IMIX  is  filled  as  follows: 

Attribute  1-30  are  the  number  of  rounds  of  each  arrmo  type  the 
truck  will  carry. 

Attribute  31  is  the  load  time  in  minutes  at  CSA/ATP.  Scenario 
dependent,  based  on  MMCS  data. 

Attribute  32  is  the  load  time  in  minutes  at  ASP.  Scenario 
dependent,  based  on  MMCS  data. 

(6)  IAMLVL  (2,30) -defined  at  5b(4) (e) .  Two  stock  level  objectives  for  up 
to  10  ATPs  and  30  ASPs  and  30  ammo  types  as  follows: 

Attributes  (1,  l),  (1,  2) ,... (1,  20)  are  the  ATP  stockaqe 
objectives  for  up  to  30  ammo  types.  These  ace  the  amounts  of  each  ammo  type 
the  ATP  will  try  to  maintain  throughout  the  simulation.  Scenario  deoendent. 

Attributes  (2,  1),  (2,  2),..., (2,  30)  are  the  ASP  stockaqe 
objectives.  These  are  the  ammo  levels  each  ASP  will  try  to  maintain  durinq 
the  simulation.  Scenario  dependent. 

Attribute  (1,31)  is  the  load  time  in  minutes  at  the  CSA/ATP. 
Scenario  dependent  and  based  on  MMCS  data. 

Attribute  (1,32)  is  the  load  t  me  in  minutes  at  the  ASP. 

Scenario  dependent  and  based  on  M4CS  data. 

(7)  IATPSD( 5) -defined  in  section  5b(3)(b).  Five  words  of  ATP  service 
data,  filled  as  follows: 

Attribute  1  is  the  lowest  ASP-ATP  round-robin  S&P  number.  Set  by 
the  user  to  correspond  to  the  appropriate  truck  number  from  ITRUCK. 

Attribute  2  is  the  ATP  first  priority  S&P  queue.  User  and 
scenario  dependent. 
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Attribute  3  is  the  ATP  second  priority  SS.P  queue.  User  : 
scenario  dependent. 

Attribute  4  is  the  CF A  ATP  owner  number.  User  choice  m 
accordance  with  scenario. 

Attribute  5  is  not  used. 

\8)  IQAY-flag  which  equals  1  for  daytime  ri  or  0  for  night  C'l.  Scenario 

dependent . 

(9)  TCI ST- time  of  start  of  Cl  in  decimal  minute?.  Set  at  .0005 
initially.  More  generally  it  is  the  endinq  time  of  the  previous  CT. 

(10)  TCILNG-time  of  length  of  Cl  in  decimal  minutes.  Usually  210  minutes 
for  day  Cl  and  360  minutes  for  night  Cl. 

(.11)  TIME-current  simulation  time  in  decimal  minutes.  Set  at  ze l  > 
initially. 

(12)  LUOUT-a  flag  that  directs  output  to  speci  ric  lev  ices.  Should  ro  set 

at  2  to  begin  runs. 

(13)  IRSTME  (23,3) -defined  in  section  f>b(6)  ( 1 )  is  resupoly  time  »a».  a  rot 

23  ammo  types,  3  attributes,  filled  as  follows: 

Attribute  1  is  the  weapon  set-up  time  in  minutes.  This  is  th® 
time  it  takes  a  weapon  system  to  be  prepared  to  take  on  ammo  once  the  ammo 
truck  arrives  in  the  weapons  area.  Scenario  dependent. 

Attribute  2  is  the  load  time  per  round  in  minutes/1000.  Scenario 

dependent . 


Attribute  3  is  the  one  way  travel  time-in  minutes-to  weapon. 

It's  computed  based  on  the  approximate  distance  that:  the  trucks  are  like'i"  to 
be  from  the  weapons  systems  they  support  and  the  travel  speed  of  the  truck  foi 
50%  cross  country  and  50%  secondary  roads.  Scenario  dependent. 

(14)  I  TYPE  (9,6) -defined  at  5b(2)  (e)  ,  speed  and  maintenance  data  f  i 
vehicle  types,  6  attributes  each,  filled  as  follows: 

Attribute  1  is  the  secondary  road  night  speed  in  KPH.  This  is 
scenario  dependent.  Used  for  determining  arrival  time  of  a  unit  truck  ar  ATP 
or  ASP  at  night.  For  truck  types  8  and  9  this  has  been  reserved  for  the 
standard  deviation  of  MTTR  for  5/10  ton  trucks  and  S&Ps,  respectively. 

Attribute  2  is  the  secondary  road  day  speed  in  KPH.  Scenario 
dependent.  Used  for  determining  arrival  time  of  a  unit  truck  at  ATP  or  ASV> 
during  the  day. 
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Attribute  3  is  the  highway  night  speed  in  KPH.  Scenario 
dependent.  Used  in  calculating  the  arrival  time  of  an  S&P  truck  travel ina  at 
night. 

Attribute  4  is  the  highway  day  speed  in  KPH.  Scenario 
dependent.  The  speed  of  an  S&P  truck  on  a  highway  during  the  day. 


Attribute  5  is  the  mean  time  between  failures  vehicle  type 
dependent.  Log  Center  data. 


Attribute  6  is  the  mean  time  to  repair.  Vehicle  type  dependent. 
Log  Center  data. 


(15)  INTER  (lO)-defined  at  5b(6)(c).  10  words  filled  as  follows: 


Attributes  1-2  are  the  counters  for  zone  1  and  2  trucks  killed, 
respectively.  Set  to  zero.  Unit  trucks  forward  of  ATP  are  in  zone  1,  others 
in  zone  2. 


Attributes  3-4  are  the  number  of  trucks  killed  in  zone  1  and  2, 
respectively.  Scenario  dependent. 

Attributes  5-6  are  the  replacement  times  for  trucks  lost  in  zone 
1  and  2,  respectively.  Scenario  dependent. 

Attributes  7-8  are  the  modulo  of  trucks  to  be  killed  in  zone  1 
and  2,  respectively.  Everytime  a  truck  enters  the  zone  it  is  counted.  When 
this  count  reaches  the  modulo  number  that  truck  is  interdicted.  User 
decision,  based  on  the  number  of  trucks  killed  and  the  number  in  the  zone. 

Attributes  9-10  are  the  number  of  zone  1  and  2  trucks  entering 
routine  HVTRDK.  Initialize  to  zero. 

(16)  LPPAR (8) -defined  at  section  5b(6)(f),  system  parameters,  all 
scenario  dependent,  set  as  follows: 

Attribute  1  is  the  total  number  of  armo  codes,  up  to  30  for  this 
version  of  ARM. 

Attribute  2  is  the  number  of  airmo  codes  at  ATP,  up  to  10  for  this 
version  of  ARM.  Scenario  and  doctrine  dependent. 

Attribute  3  is  the  maneuver  unit  ammo  codes  at  ATP,  up  to  3  for 
this  version  of  ARM.  Scenario  and  doctrine  dependent. 

Attribute  4  is  the  number  of  trucks,  up  to  1400  for  this  version 

of  ARM. 

Attribute  5  is  the  number  of  helicopters  available,  up  to  10  for 
this  version  of  ARM. 
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Attribute  6  is  the  nu:Rbe r  of  arnno  types  at  units,  up  to  iO  .'u. 
this  version  of  ARM. 

Attribute  7  is  the  number  to  subtract  t  row  5-  ton  mix  to  got  swo 
type.  Based  upon  how  numbers  have  been  previously  assigned. 

Attribute  8  is  the  number  to  subtract  from  S&P  mix  to  »«r>o 
ty[Xi .  Based  upon  how  manners  have  been  prev  ously  assigned. 

(17)  ISERV  (iO)-defined  at  5b(4j(f),  10  words  used  for  server 
manipulation  and  counting.  If  desired,  a!)  may  Sue  initialized  to  zc  t  o 

Attribute  !  is  the  nimroi  if  servers  in  each  ATP  to  be  ;x-ib.  In 
case  ATP  is  beinq  displaced,  rids  i.;  all  '.erv-.rs.  'htherwi.se,  r; . 

choose  a  number  up  to  the  maximum  numb*  r  of  servers.  ;Jsed  when  Simula*  i 
shutting  down  of  ATI's  or  movvim.  nt  of  ATP? 

Attribute  !  is  trie  nuiiej  or  .A>P  servers  to  be  held.  ,u  i  a4'.d 
is  being  displaceo,  al i  servers.  Otherwise,  the  user  may  choose  ;  ",  ;;or^?r  in 
to  the  maximum  number  of  servers,  'looc  when  simulating  short  i.ng  d  c  a^ps 
or  movement  of  ASPs. 

Attributes  1-4  are  the  atp  and  Ah1  hol  t  queues,  i*/-. : ■, . 

User  choice,  consistent  with  the  queue  list  and  trie  first  2  at t r lb-c- . 

Attributes  5-6  are  the  number  of  interdicted  AYP  and  >v;P, 
respectively.  One  of  each  may  be  interdicted  as  scenario  dictate;-'. 

Attributes  7-8  are  the  minutes  servers  are  to  be  held  it  IT-'  hoi  d 
queue  at  ATP  and  ASP,  respectively.  User  decision.  Amount  of  tiny-  &'!v  v  s1’ 
is  shut  down  or  on  the  move. 

Attributes  9-10  ate  not  used. 

d.  Building  and  Editing  Data  Files.  ARM  data  bases  are  initial  i  1  and 
edited  using  the  EDIT  program.  Though  not  an  absolute  necessity,  du, ins  t he 
initialization  process,  it  is  advantageous  to  begin  with  a  sample  data  base 
such  as  that  described  in  Volume  III.  This  allows  the  operator  to  use  an 
existing  data  base  printout  and  with  the  data  base  description  and  section  Sc 
make  penciled  changes  for  use  as  an  input  sheet.  This  is  the  procedure 
described  herein.  The  data  base  is  printed  out  in  the  order  shown  in  sort  ion 
5c.  The  arrays/variables  are  listed  in  the  order:  I ATP,  IASP,  I UN IT,  LTiniCK, 
I  TYPE,  IMIX ,  IAMLVL,  IATPSD,  I  DAY,  TCIST,  TCILNG,  TIME,  I.U0UT,  IRSTME,  IMTX, 
INTER,  LPPAR,  and  ISERV.  Having  made  the  changes  necessary  on  the  printout , 
the  user  is  then  ready  to  enter  then  at  the  computer  terminal.  The  suggested 
procedure  is  to  enter  the  changes  in  the  order  they  appear  on  the  printout. 
Examples  of  how  to  make  such  entries  are  the  purpose  of  this  section.  It 
should  be  remembered  that  in  most  real  applications  the  process  is  more 
lengthy  than  it  may  appear  here.  These  instructions  are  for  the  initial  data 
base.  Editing  the  data  base  in  later  CIs  is  done  as  described  in  Chapter  6, 
Running  a  Cl. 
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The  following  instructions  are  displayed  in  two  columns.  The  first 
contains  an  ordered  list  of  user  responses.  The  user  responses  have  been 
underlined  for  emphasis  though  they  should  not  be  when  actually  running  the 
program.  They  are  the  information  the  user  enters  at  the  computer  terminal. 
The  system  messages  may  be  informational  in  nature  or  they  may  be  prompts, 
asking  the  user  to  respond  to  certain  options.  The  second  column  consists  of 
any  clarifying  remarks  concerning  what  appears  in  the  first  column.  None  of 
these  remarks  are  actually  displayed  to  the  user.  The  instructions  assume  the 
user  being  already  logged  on  to  a  UNIVAC  System  1100  corputer  at  a  COT 
terminal.  For  further  information  concerning  the  1100  Executive  Control 
Language  and/or  its  Symbolic  Stream  Generator  (SSG)  the  user  is  referred  to 
the  applicable  UNIVAC  documentation.  More  information  pertaining  to  the  ARM 
subroutine  descriptions  and  executive  lanquage  runstreams  is  located  in  Volume 
II  of  this  documentation. 
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USER  INSTRUCTIONS  FOR  BUILDING  AND  EDITING 
MAIN  ARM  DATA  FILLS 


USER  RESPONSES 

AND  SYSTEM  MESSAGES  REMARKS 

gASG,CJP  TDATABCI01  (+1) .  Makes  the  file  TDATABC 1 0 1  f  + 1 1  . ,  <•  r,  i . 

is  to  ;je  input  to  EDIT,  avaiiar.L 
use  on  this  run. 


READY  System  message  that  previous  'fate, tv  c 

has  been  processed  and  system  «s  ready 
for  next. 


(jCCPY  DATABCI01.  ,TDATABCI01 (+1)  ,  Transfers  a  copy  of  the  alreuiv 

existing  data  base,  DATA  FA’  I  0  mf.- 

TDATABCI01 (+1)  . 

EAJRPUR  28R3  S74T11  04/07/83  Piles  are  successfully  copied 

13:44:35  24  Blocks  copied 


0FREE  TDATABClOl(-tl)  . 
READY 

@SSG  ARMPL.EDITYES 


SSG  20R1  S74T27  03/08/83 
08:46:09 

SGS 

EDIT  CI00,CIQ1 


Frees  file  from  the  run. 


SSG  control  statement  is  used  to  out 
ARMPL.EDITYES  into  machine  readable 
card  images. 

The  SSG  has  been  invoked  at  this  date 
and  time. 

Provides  information  for  use  by  the  SSG. 

The  CI00  data  base  is  to  be  edited  to 
produce  a  new  data  base,  CI01 ,  for  the 
first  Cl. 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 


REMARKS 


ARMPL.EDIT  execution  is  begun. 


gXQT  ARMPL.EDIT 

END  SSG.  ERRORS :/ 0/0/0 

TIME:  3.578  STORAGE:  6336/0/ 

6368/053777  LINES:  9/9 

RETAIN  LEVEL  1.2 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

ZERO  COUNTERS?  (YES  or  NO) 


N 

Modify  INTER,  I DAY ,  TCILNG, 
ASP  STATUS 
??? 


9 

( 1)  -EDIT  DATA  FILES 

(2)  -UPDATE  FA  CURRENT  SUPPLY  (TO 

100  Percent) 

(3)  -CLOSE  ATP 

(4)  -MODIFY  TRK  QUEUES 

(5)  -PR IOT  TRUCK  QUEUES 

(6)  -STOP 


The  SSG  process  has  been  completed 
with  no  errors  detected. 


An  affirmative  answer  will  zero 
counters  in  INTER,  ISERV,  IATP,  ISASP, 
and  set  TCIST  to  the  current  game 
time.  Also  TCILNG  is  set  to  a 
standard  of  240  minutes.  A  negative 
response  is  entered  when  building  the 
initial  data  base.  Thereafter,  a 
positive  response  is  given. 


A  system  message  reminding  the  user  it 
is  now  time  to  begin  performing 
editing  functions.  A  menu  of  editing 
options  may  be  requested  by  entering  a 
"9"  here.  Should  the  user  already  be 
familiar  with  the  menu  he  can  begin 
editing  directly  by  entering  the 
number  for  the  desired  option. 

Editing  menu  request. 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 


REMARKS 


IT? 

1 

VARIABLE  NAME 

I TRUCK  17 

L  2 

[TRUCK  17 
ATTRIBUTE  2  = 

I  UNIT  22  23 

L  4  5 

I UNIT  22 
ATTRIBUTE  4  = 
ATTRIBUTE  5  = 

I UNIT  23 
ATTRIBUTE  4  = 
ATTRIBUTE  5  * 

I TRUCK  18 

C  4  5 

I UNIT  20  25 


An  explanation  of  the  option?:  ; r,v 
follows,  beginning  with  RUT’ 

FILES  The  user  may  now  access  try.- 
data  elements  from  the  data  base 
description. 

=  The  variable  of  interest  ma^  now  re¬ 

addressed. 

The  seventeenth  element  of  [he  array 
ITRUCK  is  now  available. 

User  commands  are  the  LIST  or  L,  the 
CHANGE  or  C,  and  the  LEAP  or  SKIP. 

The  two  periods  indicate  the  system  is 
waiting  for  a  command. 

The  user  has  asked  to  see  the  second 

attribute  of  ITRUCK  17. 

The  requested  value  is  printed  on  the 
(value)  screen  where  the  parentheses;  indicate. 


Here  the  user  has  requested  display  of 
I UNIT  22  and  IUNIT  23,  attributes  4 
and  5. 

The  requested  display  is  shown. 

(value) 

(value) 


(value) 

(value) 


Now  access  to  all  elements  of  [TRUCK 

18  is  requested. 

Using  the  CHANGE  or  C  command  ITRUCK 
18,  attribute  4  is  chanqed  to  a  value 
of  5. 

All  elements  of  [UNIT  20  thru  VUNTT  25 
are  accessed. 

The  requested  lUNITs  20-25  heave 
attribute  4  set  to  a  value  of  6. 


C  4  6 


A 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 

I  ATP 
C  5  0 

I TRUCK  1  10 

LEAP  4 

L  1 

I TRUCK  1 

ATTRIBUTE  1  =  (value) 
ITRUCK  5 

ATTRIBLTTE  1  =  (value) 
ITRUCK  9 

ATTRIBUTE  1  =  (value) 

LPPAR  1 

SKIP  3 


REMARKS 


The  entire  IATP  array  is  requested. 
Throughout  IATP  attribute  5  is  zeroed. 


Now  the  LEAP  and  SKIP  commands  will  be 
addressed.  LEAP  allows  the  user  to 
address  selected  variables  from  an 
array,  i.e.,  every  second  variable, 
every  third  variable,  etc.  Here  the 
first  10  variables  in  the  ITRUCK  array 
are  accessed. 


Every  fourth  variable  between  ITRUCK  1 
and  ITRUCK  10  is  requested. 


The  first  attribute  of  those  variables 
is  to  be  listed. 


The  array  LPPAR  is  accessed. 


Unlike  the  LEAP  command,  the  SKIP  will 
enable  the  user,  in  the  same  fashion, 
to  select  certain  attributes  of  a 
variable.  Here  every  third  attribute 
is  selected. 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 


L 

LPPAR  1 
ATTRIBUTE  I 
LPPAR  1 
ATTRIBUTE  4 
LPPAR  I 
ATTRIBUTE  7 

I 'TRUCK  1  5 

LEAP  4 
SKIP  4 
L  1  10 
I 'TRUCK  1 
ATTRIBOTE  1 
ATTRIBUTE  5 
ATTRIBUTE  9 
ITRUCK  5 
ATTRIBOTE  1 
ATTRIBUTE  5 
ATTRIBOTE  9 
END 


remarks 


=  (value) 


=  (value) 


=  (value) 


Here  the  two  commands  will 
together . 


=  (value) 
=  (value) 
=  (value) 


=  (value) 
=  (value) 
=  (value) 


No  further  commands  in  the  EDIT  DATA 
FILES  Cation  are  requested  at  this 
time. 


??? 


As  before,  the  menu  may  be  disolayed. 
This  time  the  next  option  is  asked  for 
instead. 


USER  RESPONSES 

AND  SYSTEM  MESSAGES  REMARKS 


2  The  update  FA  current  supply  (100%) 

option  is  selected.  Since  the  data 
base  being  edited  already  contains 
data,  it  may  be  desirable  to  simulate 
previous  stockpiling  of  artillery 
ammunition.  The  procedure  is 
accomplished  automatically.  For  all 
FA  I UNITS,  words  10  and  11  are  zeroed, 
and  word  12  becomes  the  arithmetical 
product  of  words  9  and  15. 

??? 

6  Now  the  CLOSE  ATP  option  is  selected. 

ENTER  (CFA)  ATP  NUMBER  The  CFA  ATP  number  may  now  be 

mO  BE  CLOSED  entered.  In  this  case  a  value  of  '6' 

has  been  equated  to  the  CFA  ATP. 

6  ATP  6  will  be  closed.  Its  S&P  trucks 

pulled  out,  redistributed  to  other 
ATPs,  and  its  amnunition  left  on  the 
ground.  ATP  6  should  be  selected  as 
it  is  the  CFA  ATP. 

END  ATP  closings  have  been  completed. 

??? 

4  The  MODIFY  TRK  QUEUES  option  is 

selected.  In  developing  the  data  base 
it  is  necessary  to  assign  all  trucks 
to  their  respective  queues  (units) . 

In  the  ITRUCK  array  of  the  data  base 
the  trucks  were  assigned  owner  numbers 
coinciding  with  the  I UNIT  array 
numbers.  In  order  for  the  model  to 
find  these  trucks  it  is  necessary  to 
put  the  trucks  in  their  respective 
queues.  For  example,  all  trucks 
assigned  to  owner  10  must  be  put  into 
queue  10  and  trucks  assigned  to  an  ATP 
which  have  on  board  the  initial 
stockage  of  ammunition  at  the  ATP  must 
be  put  in  the  right  queue  for  that 
ATP.  The  complete  truck  queue  list 
appears  in  the  data-base  description. 
Trucks  that  will  be  set  in  motion  at 
the  beginning  of  the  game  should  not 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 


GET  3  35 

P  3  36 

LIST  105 

49 

51 

52 

P  4,10  36 

T 

ENTER  QUEUE  NUMBER  (999 
OUT  FROM  ALL  QUEUES) 

no 

END 

??? 

5 


PF'MARKS 


be  placed  in  a  queue.  This  is  any 
truck  assigned  a  status  code  4. 
Commands  available  for  this  our  i  ,r,  , 
GET  or  G,  TAKE  or  T,  LIST  or  I  ard 
PITT  or  P.  Some  command  examples 
follow. 

System  is  awaiting  command. 

Truck  3  is  removed  from  queue  15 


Truck  3  is  placed  in  queue  36. 


A  request  for  a 
trucks. 

A  list,  of  queue 


list  of  queue  105 

105  trucks. 


Trucks  4  through  10  are  placed  in 
queue  36. 


The  TAKE  command.  A  queue  number 
TO  TAKE  will  zero  a  queue  of  all  trucks.  A 
999  will  zero  all  queues. 


No  further  truck  queue  processing  is 
desired. 


The  PRINT  TRUCK  QUEUES  option  is 
called.  A  hardcopy  listing  of  all 
queues  with  the  truck  numbers  of  the 
trucks  they  contain  is  now  assembled 
for  printout  after  the  terminal 
session  concludes. 
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USER  RESPONSES 

AND  SYSTEM  MESSAGES  REMARKS 

??? 


SSG  ARMPL.DP  WILL  SYM  THIS  REP  CRT 


@SSG  ARMPL.DP 

SSG  20R1S74T27  03/08/83 
08:50:42 

SGS 

DP  CI01 


@ 


END  SSG.  ERRORS:  /0/0/0 

TIME:  3.572  STORAGE: 

6336/0/6368/053777 

LINES:  7/7 

RETAIN  LEVEL  1.2 

READY 

READY 

READY 

READY 

READY 

READY 

§XQT  ARMPL.DATA 


ENTER  Cl  NUMBER 

01 

ENTER  ARM  DATA  BASE  CPTICNS 


The  STOP  option  is  picked,  signifvinq 
that  editing  is  currently  conplete. 

This  is  a  reminder  to  the  operator 
that  commands  are  to  he  issued  now  to 
transmit  and  print  the  new  ARM  data 
base  and  the  Truck  Queue  Peport  from  a 
remote  site  to  the  DPFO  computer  (if 
desired) . 

This  initiates  the  action. 

The  SSG  is  invoked  at  this  date  and 
time. 

Provides  input  for  the  SSG. 

This  inserts  a  necessary  control  card 
for  the  SSG. 

Signifies  that  all  SSG  information  has 
been  provided. 

Indicates  successful  SSG  process inq. 


Begins  execution  of  the  program  that 
will  print  the  ARM  data  base. 

A  prompt  to  enter  the  new  Cl  number. 

The  two  digit  new  Cl  number. 

Here  a  menu  has  been  suppressed.  A 
"1"  option  will  print  out  the  complete 
data  base.  It  is  always  most 
advantageous  to  select  this  option  to 
have  all  the  information  together  and 
the  printout  is  small  enough  not  to  be 
unwieldy.  An  example  of  this  printout 
appears  in  Volume  III. 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 


REMARKS 


1 

0FREE  2  Sy.btt.vi  reminders  to  obtain  ctt  •<:*  • 

@SYM  DPCI —  (or  SYM,U  DPCI —  if  desired.  The  Syin,  u  opt- a. 

necessary  to  save  a  human  -• 

file. 

File  2  is  released  from  the  r-.n. 


Schedules  printing  cooies  of  t'i  r;  int 
file  and  directs  them  to  t.i:e  M 
computer. 

Terminal  session  is  now  uomoiere.  Tn® 
new  data  base  resides  on  file 
DATABCI01 . .  Some  accounting 
information  now  prints  to  the  r...-i . 

e.  Building  the  Events  File.  In  the  running  of  an  initial  ARM  Ml  no 
affirmative  reply  is  given  to  the  prompt  "DO  YOU  WISH  TO  ADD  EVENTS?".  This 
reply  will  result  in  the  reading  in  of  an  initial  events  tape  created  through 
the  use  of  programs  ADDEVT  and  CCNVRT.  ADDEVT  allows  the  user  to  create  a 

source  tape  file  on  a  Fil.  12  called  TEVENTSCI _ ,  where  the  underscores  stand 

for  the  two  digit  Cl  number.  CCNVRT  then  converts  the  file  to  binarv  for  us® 
in  the  ARM  program.  Instructions  for  the  use  of  these  programs  follows.  An 
events  tape  may  be  read  in  prior  to  any  Cl,  but  it  is  necessary  before  running 
the  initial  one.  ARM  is  set  up  to  require  an  initial  "push"  of  S&Ps  from  the 
CSA  to  replenish  stockage  objectives  at  the  ATPs  and  ASPs.  Cnee  this  is  done 
initially  the  process  will  continue  on  its  own. 


TO  SAVE  FILE) 

gFREE  2 
READY 

@SYM,U  DPCI01 

@FIN 
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ADOKVT  USER  INSTRUCTIONS 


USER  RESPONSES 

AND  SYSTEM  MESSAGES  REMARKS 

@SSG  ARMPL . ADDEVTSARM  Program  is  made  into  machine  readable 

card  imaaes.  SSG  is  invoked. 

SSG  20R1S74T27  02/27/83 
08:25:29 


SGS 

ADD  Cl (N) 


0XQT  ARMPL. ADDEVTS 

END  SSG. ERRORS:  0/0/0 

TIME:  3.572  STORAGE: 

6336/0/6368/053777 

LINES  9/9 

RETAIN  LEVEL  1.2 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

ENTER  EVENT  TYPE,  PARNB ,  TIME, 
SEPARATED  BY  COT-MAS 
ENTER  0,0, 0,0,0  TO  COMPLETE 
ADDITION  OF  EVENTS 
??? 

5,1,500,2,0,5,50. 


? 


0,0, 0,0,0 


Input  being  provided  to  SSG. 

'N*  is  the  Cl  for  which  events  are  to 
be  entered  expressed  by  two  digits 
with  leading  zeroes  if  necessary. 

Program  is  executed. 

Message  and  series  of  "READY"s  is 
displayed,  then  user  prompts  begin, 
SSG  processed  successfully. 


User  prompt  to  begin  entering  events. 
Event  types  and  their  parameters  are 
listed  in  the  Data  Base  Description  of 
this  chapter.  The  TIME  is  the  event 
time. 

A  truck  arrival  at  ASP  2  for  truck 
50 0,  50  minutes  into  the  simulation 
run  has  been  scheduled.  The  zero  is  a 
required  entry  even  thouah  that 
parameter  is  not  applicable  to  a  type 
5  event.  If  an  incorrect  event  type 
is  entered  the  message: 

"INCORRECT  EVENT  TYPE" 


»» 9»» 


is  displayed  and  another  event  may  be 
entered. 

Prompt  for  entry  of  another  event. 

All  events  have  been  entered. 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 

DO  YOU  WISH  TO  SEE  EVENTS - 

Y  OK  N 

N 

PUT  EVENTS  ON  FILE  12 - Y  CR  N 

Y 

EVENTS  NOW  ON  FILE  12 
@FIN 


PPMARKS 

An  affirmative  reply  will  1  i  - 
event'  in  the  ord^r  entetvd  e 
co  lumns . 


A  negative  answer  will  ston  the 
oroqram  with  no  events  havina  he 
entered. 


Terminal  session  ended. 


CCNVRT  USER  INSTRUCTIONS 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 


@SSG  ARMPL.CCNEVFNTS 

SSG  20R1S74T27  02/28/83 
08:55:30 

SGS 

CCN  Cl (N) 


gXQT  ARMPL . CQNVRT 

END  SSG. ERRORS:  0/0/0 
TIME:  3.572  STORAGE: 

6336/0/6368/053777 
LINES  9/9 
RETAIN  LEVEL  1.2 
READY 
READY 
READY 
READY 
READY 
READY 
READY 

FILE  11  IS  NOW  COMPLETE  Events  tape  is  successfully  processed. 


PEMAPES 


SSG  is  invoked  to  out  nrogr am  into 
correct  format. 

SSG  beqins. 


Inputs  to  be  provided  SSG. 

'N'  is  the  Cl  to  be  done  now.  Express 
as  two  diqits  insertinq  leadino  zeroes 
if  necessary. 

Program  execution  beqins. 

SSG  processing  successfully  complete^. 


@FIN 


Terminal  session  completed. 


f.  Building  Distance  Files.  In  every  Cl  :  dz.-:t anc**  file  is  r 
I  UNIT  array.  It  describes  the  distances  betwr»  n  the  center  of  mass  o 
batteries  or  maneuver  units  and  their  servicing  ASP  '•'•TP.  It  is  buiit 
initially  in  program  UNITOTST.  After  the  mi'. a!  Cl  >t  is  modified 
program  MCDDIST.  The  two  programs  are  verv  iiuch  ..like  their  basic  Mi 
being  that  UNITDIST  creates  a  file  and  MOOD  1ST  modifier  the  contents 
existing  file.  Instructions  for  runnino  thes  -  r.roorams  follow.  '  m 
information  is  placed  on  a  File  13. 


f  t- 
r.  I  rv  j 
of  r 
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UNI TP I HT  USER  INSTRUCTIONS 


USER  RESPONSES 

AND  SYSTEM  MESSAGES  REMARKS 


@ASG,UP  DISTFILECI (N+l) 


READY 

@USE  13,  DISTFILECI (N+l) 

READY 

gXQT  ARMPL.UNITDIST 

ENTER  UNIT  NUMBER  (99  TO  END) 


1 


ENTER  ATP,  ASP,  ATP  DISTANCE, 
ASP  DISTANCE 

SEPARATE  ENTRIES  BY  COMMAS 


1,1,65,10 


ENTER  UNIT  NUMBER  (99  TO  END) 
99 

DO  YOU  WISH  TO  SEE  VALUES 
(Y  CR  N)? 


A  distance  file  is  made  available  for 
this  run.  'N'  is  the  two  diqit  Cl 
number  (leadinq  zeroes  if  necessary) 
to  which  these  distances  will  applv. 


Program  is  directed  to  write  to  a  file 
13. 


Program  is  executed. 

User  prompt  to  enter  unit  numbers  to 
build  a  file  containing  ATP  and  ASP 
distances  from  the  center  of  mass  of 
the  batteries  or  maneuver  units. 

Unit  number  =  1.  If  an  inapplicable 
number  is  entered  the  message 
"INCORRECT  ENTRY"  is  displayed  and  the 
program  returns  to  the  previous  prompt. 

Any  entry  that  has  an  out  of  bounds 
value  will  send  the  program  back  to 
the  previous  prompt  after  displaying 
"INCORRECT  ENTRY”. 

A  sample  entry  is  made.  ATP1  and 
ASPl  are  assigned  distances  of  65  and 
10  respectively. 

The  original  pronpt  is  repeated. 

The  sample  entries  are  complete. 

If  answered  affirmatively  the  values 
for  all  units  are  displayed,  as  they 
were  entered,  with  the  unit  number 
followed  by  the  four  columns  of 
entries. 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 

N 

PUT  CN  TAPE  (Y  GR  N) 

N 

ENTER  UNIT  NUMBER  TO  CORRECT 
1 

UNIT  NO.  ATP  ASP  ATP  DIST  ASP  DIST 
1  1  1  65  10 

ENTER  UNIT  NUMBER  (CHANGE  IF 
NECESSARY) 

1 

ENTER  NEW  ATP,  ASP,  ATP  DIST, 

ASP  DIST. 

1,1,90,10 

ANY  MORE  UNITS  TO  CORRECT  (Y  CR  N) 

N 

PUT  CN  TAPE? 

Y 

TAPE  13  IS  COMPLETE 
STOP  1232 


REMARKS 


If  "v"  the  entries  are  written  to  a 
tape  ant!  the  program  ends. 


A  correction  to  the  ASP  distance  wil 
be  shown  here  for  Unit  1 . 

System  display  of  current  value.-'. 


Correcting  the  ATP  distance  to  90  km. 

If  "Y"  proqram  returns  to  "pNTFR  iiNTT 
NUMBER  TO  CORRECT”. 


If  "N"  the  messaqe  "WISH  TO  exit 
PROGRAM"  is  disolayed.  This  promt 
should  be  answered  aff irmativelv , 
causing  the  proqram  to  stop,  and 
necessitating  a  later  rerun. 


System  message  of  successful 
termination. 


@FIN 


Terminal  session  is  completed. 


MODDIST  USER  INSTRUCTIONS 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 


0SSG  ARMPL .  RINDI ST 
SSG  20R1S74T27  02/27/83 
08:30:31 

SGS 

DIST  Cl  (N)  ,CI  (N+l) 


gXQT  ARMPL .MODDIST 

END  SSG. ERRORS:  0/0/0 

TIME:  3.572  STORAGE: 

6336/0/6368/053777 

LINES  6/6 

RETAIN  LEVEL  1.2 

READY 

READY 

READY 

READY 

READY 

READY 

WISH  TO  EDIT  ALL  CR  SOME 
(A  CR  S)? 


S 


RFWARKS 


Program  put  into  machine  readable 
form.  SSG  is  invoked. 


Input  being  provided  to  SSG. 

Distance  files  for  former  and  current 
CIs  are  provided.  'N'  again  in  two 
digits  with  leading  zeroes  if 
necessary. 

Program  execution  begins. 

SSG  has  processed  successfully. 


If  "A",  entries  are  displayed  and  the 
user  is  asked  whether  or  not  he  wants 
to  put  them  on  tape.  If  "y"  program 
is  exited.  If  "N"  proqram  is  routed 
the  same  as  if  "S"  had  been  chosen  in 
the  first  place. 

Instructions  are  substantially  the 
same  as  for  UNITOIST  hereafter.  If 
the  'S'  option  is  chosen  a  display  of 
values  for  all  units  is  shown,  though 
not  in  this  exanple,  for  brevity. 

Format  is  five  columns  headed: 

UNIT  NO.  ATP  ASP  ATP  DIST  ASP  DIST 
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USER  RESPCNSES 
AND  SYSTEM  MESSAGES 


REMARKS 


ENTER  UNIT  NUMBER  (99  TO  END) 


1 


ENTER  ATP,  ASP,  ATP  DISTANCE, 
ASP  DISTANCE 

SEPARATE  ENTRIES  BY  COMAS 


1,1,18,25 

ENTER  UNIT  NUMBER  (99  TO  END) 
99 

DO  YOU  WISH  TO  SEE  VALUES 
(Y  CRN)? 


N 

PUT  CN  TAPE  (Y  OR  N) 


N 

ENTER  UNIT  NUMBER  TO  CORRECT 
1 


ENTER  NEW  AT  ATP,  ASP,  ATP 
DIST.,  ASP  DIST. 

1,1,18,30 

ANY  MORE  UNITS  TO  CORRECT 
(Y  CR  N)? 


User  prompt  to  enter  unit  unmoor ■'  i 
buijd  h  file  containinq  ATp  and  ac-p 
distances. 

Unit  numb-er  -  1.  If  an  inappl  i  -able 
number  is  entered  the  iressaqe 
"INCORRECT  ENTRY"  is  displayed  and  the 
proqram  returns  to  the  previous  prompt 

Any  entry  that  has  an  out  of  hounds 
value  will  send  the  oroqram  back  to 
the  previous  prompt  after  disolaviro 
"INCCRPECT  ENTRY”. 

A  sample  entry  is  made. 

The  oriqmal  prompt  is  repeated. 

The  sample  entries  are  complete. 

If  answered  affirmatively  the  value. - 
for  all  units  are  displayed,  as  the- - 
were  entered,  with  the  unit  num’v-r 
followed  by  the  four  columns  oF 

entries. 


If  "Y"  the  entries  are  written 
tape  and  the  program  ends. 


A  correction  to  the  ASP  distance  v.-i 1 ! 
be  shown  here  for  Unit  1. 


Correcting  the  ASP  distance  to  10  km. 

If  "Y"  proqram  returns  to  "ENTER  UNIT 
NUMBER  TO  CORRECT". 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 

POT  CN  TAPE? 


Y 

TAPE  13  IS  COMPLETE 
@FIN 


REMARKS 


If  "N"  the  messaqe  "WISH  TO  EXIT 
PROGRAM"  is  displayed.  This  should  be 
answered  affirmatively,  causing  the 
program  to  stop,  and  necessitating  a 
later  rerun. 


Terminal  session  is  complete. 
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6.  USER  INSTRUCTIONS. 

a.  Overview.  Following  the  initial  Cl  the  running  of  ARM  becomes  an 
iterative  process.  This  consists  of  reading  in  the  current  data  base, 
applying  any  necessary  changes  to  it;  readinq  in  the  demand  from  the  attritio' 
model;  simulating  the  Cl;  and  generating  output  in  the  form  of  printed  report* 
and  a  newly  modified  data  base.  Having  accomplished  these  steps,  the  ,n.  \T 
is  run  by  incrementing  the  Cl  number  and  repeating  the  process. 

b.  Running  a  Cl.  Following  are  the  steps  to  be  taken  to  run  ARM  CT.s. 
Much  of  what  is  presented  has  already  been  explained  in  the  previous  chapter 
under  Building  and  Editing  Data  Files.  Where  a  duplication  does  occur  it  is 
noted,  a  brief  description  given,  and  the  user  referred  to  the  earlier  chants 
for  more  information.  The  format  and  assumptions  retain  the  same  as  in  the 
preceding  material.  For  more  details  of  the  ARM  programs  and  subroutines  the 
user  is  directed  to  Volume  II,  the  Programmer’s  Manual. 
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USER  INSTRUCTIONS  PCR  RUNNING  ARM 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 


gSSG  ARMPL,RUN 


SSG  20R1  S74T27  03/09/83  08:37:24 
SGS 

FILES  Cl (N) ,  CI{N+1),  LOG(N) 


@ 


END  SSG. ERRORS :/0/0/0 

TIME: 3. 584  STORAGE:  6336/0/6368/ 

RETAIN  LEVEL  1.2 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

READY 

FACILITY  REJECTED  4001000000 

READY 

READY 

READY 


REMARKS 

Puts  ARMPL.RUN  into  machine  readable 
format. 


Provides  information  to  the  SSG. 

List  of  files  to  be  used.  N  is  the 
current  Cl  and  N+l  the  next  Cl.  The 
Cl  files  contain  the  ARM  data  bases. 
The  Log  file  has  the  demand 
information  from  the  attrition  model. 
Both  are  expressed  by  two  diqit 
numbers  (i.e.,  include  lead  zeroes, 
when  applicable) . 

Signals  SGS  that  all  information  has 
been  provided. 


This  statement  normally  appears  for  all 
Cls  after  CI01.  It  is  due  to  the  fact 
that  there  is  no  file  for  additional 
events  created  by  gamer.  If  you  want 
to  create  additional  events  see 
program  ADDEVT,  described  in  Chapter  5. 


SSG  is  involved  at  this  time. 


The  SGS  has  been  completed 
successfully. 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 


RFMARKS 


gXQT  ARMPL.ARM 
QNIT 

ARE  YOU  CREATING  AN  ANSWER 
FII£  (Y  OR  N) 

N 

DO  YOU  WISH  TO  ADD  EVENTS? 


Y 

ENTER  TIME  TO  STOP  SIMULATION 
2160.1 


(INITIALIZE  TRUCKS  TIMES  SINCE 
LAST  FAILURE] 


TIME=1920. 1 


9 


The  inn  i  n  ''EM  m  opt  am  ir.  execut'd. 

Messaqe  i nd i cat ing  an  in j  tial i ?at i on 
routine  for  thin  Cl  is  called 

Statement  is  no  lonqer  applicable. 
Function  is  now  performed  in  program 
EDITYES.  A  negative  reply  should  lie 
g iven . 


Answer  in  the  affirmative  for  the  *  ir.-v 
Cl  and  negative  thereafter,  in  the 
first  Cl,  an  extra  file,  created  in 
program  Anni-VT  is  read  in.  This 


program  is  explained 


"hapter 


an' 


will  allow  the  user  to  build  file  o 
initial  events. 


The  time  the  run  is  to  stop  in  r hit- 
example.  This  is  normally  240  or  36f> 
minutes  from  the  current  Cl  start  time 

The  brackets  here  are  to  indicate  that 
this  message  appears  only  on  the 
initial  Cl.  It  is  always  answered 
positively. 

The  current  simulation  time  i:  now 
di splayed. 

This  is  to  alert  the  user  that  he  mas 
now  choose  to  display  the  ARM  menu. 

CD  input  of  any  number  greater  than  or 
equal  to  eight  the  menu  is  displayed. 
Any  number  from  one  to  seven  allows 
the  user  to  address  the  desired  notion 
directly. 

The  user  requests  the  menu. 


(1)  EDIT  DATA 

(2)  WRITE  REP CRT 

(3)  SCHEDULE  CONTROL 


The  ARM  menu  and  current  simulation 
time  appear. 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 

(4)  RETURN 

fS)  STOP  SIMULATION  NOW 

(6)  EDIT  TRUCK  QUEUES 

(7)  CREATE  EVENTS 
TIME=1920.1 

1 


VARIABLE  NAME= 


INTER 


C  3  10 


REMARKS 


EDIT  DATA  option  is  chosen.  This 
allows  the  user  to  perform  editing 
functions  described  in  the  previous 
chapter  under  the  EDIT  DATA  FILES 
option  of  the  EDIT  program.  It  should 
be  noted;  however,  that  ^hanqes  made 
in  this  way  do  not  permanently  chanqe 
the  data  base  in  case  a  rerun  becomes 
necessary.  Only  a  brief  example  will 
be  given  here. 

Request  for  the  name  of  the  variable 
to  be  accessed. 

INTER  is  selected.  This  relates  to 
truck  kills. 

Word  3  is  set  eoual  to  10. 


END 

TIME  =  1920.1 
? 

2 

ENTER  NUMBER  CF  ACTIVE  ATPS 
(1,2,...,  or  10) 


Editing  is  done  for  now. 
Current  simulation  time. 
Request  for  menu  option. 

WRITE  REPORT  option  is  chosen. 


6 


ENTER  NUMBER  CF  ACTIVE  ASPS 
(1,2,...,  or  10) 


4  For  this  example  there  are  6  active 

ATPs  and  4  active  ASPs.  Several 
reports  result  from  this  option.  Tt»ey 
are  the  truck  report,  unit  report,  ATP 
report,  ASP  report,  and  a  trucks 
killed  or  broken  down  report.  Their 
contents  are  explained  in  chapter  7  of 
this  volume. 
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USER  RESPONSES 

AND  SYSTEM  MESSAGES  REMARKS 

TIME  =  1920.1  Current  simulation  time. 


? 

3 


ENTER  TIME  FOR  NEXT  CONTROL 


2160.05 


TIME=1920.1 

•? 

6 


END 

TIME  =  1920.1 


Option  or  menu  choice  is  reoeatr-b. 

The  SCHEDULE-  CONTROL  opt  ion  i  a 
selected.  This  is  often  done  foi 
reasons  such  as:  the  user  wishes  to 
look  at  certain  data  values,  chance 
some  values  or  print  some  reports  iuet 
prior  to  endinq  the  Cl. 

The  user  is  prompted  to  enter  the  time 
for  ARM  to  return  to  she  cent ro' 
t  outine. 

At  2160.05  ARM  will  return  to  control 
routine  and  the  menu  will  f>-  display*'-' 
if  desired.  This  will,  allow  report 
printing  just  before  the  Cl  o;vs. 

Current  time  displayed. 

Option  or  menu  may  he  selected. 

The  EDIT  TRUCK  QUEUES  option  is 
picked.  The  user  may  now  proceed  to 
perform  the  functions  described  in  the 
previous  chapter  under  t.he  MCT/Tl-'.' 

TRUCK  QUEUES  option  of  the  ci'/n 
program. 

This  option  is  left.  Examples  vo: 

given  earlier  in  Chapter  5. 

Current  simulation  time. 


Options  or  menu  choice. 
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USER  RESPONSES 
AND  SYSTEM  MESSAGES 


REMARKS 


2 

TO  CREATE  AN  EVENT,  INPUT  AS  A  GROUP 
SEPARATED  BY  COMAS  OR  SPACES  SEVEN 
VALUES:  EVENT  TYPE  (INTEGER  VALUES 
BETWEEN  1  AND  17  5  PARAMETERS  FCF  EACH 
EVENT  (INTEGER,  DEPENDING  ON  EVENT 
TYPE)  ,  AND  TIME  (DECIMAL,  MINUTES 
REAL).  EXAMPLE  10,  1,  512,  0,  0,  0, 
2100  -  CSA-ATP  TRUCK  512  WILL  ARRIVE 
AT  ATP  AT  TIME  =  2100  MIN. 

10,1,512,0,0,0,2100. 

7 

END 

TIME  =  1920.1 

7 

[5] 


4 


HAVE  FINISHED  RDJIFF 
(other  info) 

Scheduled  stop,  time  =2160.05 
SSG  armpl.  free;  then  SSG 
armpl.  edityes 
TIME}=2160.05 


7 

2 


CREATE  EVENTS  is  called. 
Instructional  system  message. 


Looking  for  entry  of  additional  events. 

No  further  events  are  to  he  scheduled. 

Current  simulation  time. 

Cption  or  menu  choice. 

The  STOP  SIMULATION  NOW  choice.  This 
will  schedule  a  stop  simulation  event 
for  the  current  time.  In  normal 
processing  this  would  not  be  chosen, 
only  when  a  restart  is  necessarv. 
Therefore  it  appears  in  brackets. 

Normally  after  exercisina  one  or  more 
of  the  options  alternative  4  is  chosen 
to  start  the  processing  of  ARM. 

Information  that  the  input  tape  from 
the  attrition  model  has  been  processed. 
The  other  information,  not  actually 
shown  here,  consists  of  thinas  like 
when  unit  ammunition  becomes  neqative 
and  how  much  or  S  s  Ps  busy  at  an 
ATP  for  a  specific  amno  and  when, 
etc.  The  other  information  is 
displayed  to  remind  user  of  steps  to 
take  to  get  printout. 


ARM  menu  option. 

The  WRITE  REPCFT  option  is  chosen 
directly. 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 


REMARKS 


ENTER  NUMBER  CF  ACTIVE’  ATPS 
(1,2, ...or  10) 


6 

ENTER  NUM3ER  CF  ACTIVE  ASPS 
(1,2, ...or  10) 

4 

TIME  =  2160.05 

7 

4 

TIME=2160.1 

SSG  ARMPL . FREE ;  THEN  SSG 
ARMPL.EDITYES 

gSSG  ARMPL. FREE 

SSG  20R1  S74T27  03/08/83 
SGS 

EDIT  Cl  (N)  ,  Cl  (N-El) 

@XQT  ARMPL. EDIT 

ZERO  COUNTERS?  (YES  CR  NO) 

Y 

MODIFY  INTER, IDAY,TCILNG, 
ASP  STATUS 

111 


Current  simulation  time 

Menu  opt  ion . 

The  RETURN  option. 

This  is  the  end  of  simulation  t  •; m.-. 

To  remind  the  user.  This  now  :v?  d 
process  of  edition  data  for  f-e 
following  Cl. 

Putting  ARMPL. FREE  into  machine 
readable  form. 

Previous  statement  successful. 

To  send  information  to  the  SSG. 

Cl  (N)  to  lie  edited  and  renamed  Cl  i 
Executing  the  EDIT  area rat: 


EDIT  menu  option.  All  that  in  bet 
shown  now  was  explained  in  the 
previous  chapter  under  Building  an 
Editing  Data  Files.  Onlv  a  hi.  ief 
example  will  be  shown  here. 


1 


EDIT  DATA  FU.fb  notion. 


USER  RESPONSES 
AND  SYSTEM  MESSAGES 

VARIABLE  NAME= 

INTER 

C*3  3 

C  4  3 

C  7  60 

IDAY 

CIO 

TCILNG 

C  1  360 

EM) 

??? 

5 

??? 

6 

SSG  ARMPL.DP  WILL  SYM  THIS  REPORT 

gSSG  ARMPL.DP 

SGS 

DP  Cl (N) 

@ 

EM)  SSG. ERRORS :/0/0/0 

TIME:3.572  STORAGE: 6336/0/6368/ 

053777  LINES: 5/5 

RETAIN  LEVEL  1.2 

READY 

READY 

READY 

READY 

READY 


REMARKS 


Some  truck  interdiction  parameters  are 
set. 


A  360  minute  Cl  lenqth  is  selected. 
Editing  option  1  ends. 


The  STCP  option.  Editinq  is  complete. 
User  reminder. 

Preparing  machine  readable  input. 

Providing  SSG  information. 

Inserts  a  control  card  into  SGS  stream. 

Signifies  that  all  SSG  information  has 
been  sent. 

SSG  is  successful. 


A  night  Cl  is  chosen. 


The  orint  truck  queue  option. 
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USER  RESPONSES 

AND  SYSTEM  MESSAGES  ?'*V- 

gXQT  ARMPL . DATA  ARMFi  .  ’ 

INTER  Cl  NUMBER 


(N) 


•.anix.u  ic 


ENTER  ARM  DATA  BASE  OPTIONS 


Hf'|.  i  -'V  '  .  ■'  5 

1 1  '  will  i:-i  inr  'it  n )  J  jv- 
:  r.roniwt  ion . 


I 

i§FREE  2  i!~r>r  er .  ncR-r . 

@SYM  DPCI —  (OR  8  SYM,U  DPCI  — TO  Use;  rerr.i rHer . 

SAVE  FILE) 

a FREE  2 

READY 

0SYM  DPCI (N)  Retorts  are  se  ,C  r  :  -ji a 

This  comp  lev  e--  *:'•!■:•  i . 
be  incremenred  and  tne  or 
repeated  or  t  -  <•  next  Cl. 
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7.  TYPES  CF  OUTPUT.  At  the  completion  of  a  specified  period  of  simulated 
combat,  ARM  is  designed  to  provide  a  complete  status  report  on  the  armiunition 
resupply  network  of  the  division.  These  reports  scheduled  by  the  gamer  can  be 
written  at  any  time  during  the  Cl,  but  generally  are  scheduled  near  its 
completion  (see  user  instructions  for  explanation  of  scheduling  reports).  The 
report  lists  the  following  categories: 

1.  Unit  Data 

2 .  ATP  Status 

3.  ASP  Status 

4.  Unit  Truck  Resupply  In  ormation 

a.  Unit  Data.  The  unit  report  provides  the  current  status  of  each  unit, 
reflecting  unit  identification  and  type,  servicing  ATP  and  ASP  and  the 
respective  distances.  Additionally,  it  identifies  each  anmunition  tyoe  used 
by  the  unit.  For  each  type  it  specifies  the  associated  weapon,  the  number  of 
surviving  weapons,  the  current  supply  of  ammunition  on  the  weapons,  number  of 
rounds  on  the  way  to  the  unit,  the  percent  of  basic  load  on  the  weapons  and 
the  number  of  rounds  on  unit  trucks  located  at  the  unit.  Also  specified  for 
each  ammunition  is  the  total  demand  for  the  past  period  of  combat.  Included 
is  the  status  of  all  trucks  assigned  to  the  unit.  Each  truck  lists  the  truck 
number,  its  mission,  status,  mix  number  for  the  type  of  ammunition  it  is 
carrying,  the  percentage  of  its  ammunition  load  which  is  currently  left  on  the 
truck,  and  how  many  minutes  are  left  before  it  breaks  down.  Figure  7-1  lists 
an  example  of  unit  data. 

b-  ATP  Status.  For  each  active  ATP,  this  portion  of  the  report  lists  the 
number  of  unit  trucks  waiting  to  be  serviced,  and  the  status  of  anmunition 
supplies.  For  each  type  of  ammunition  stocked  at  that  ATP,  the  report  lists 
the  current  supply  on  hand,  the  current  demand  for  trucks  waiting  to  be 
serviced,  and  replenishment  rounds  which  are  on  the  way  to  the  ATP.  Fiqure 
7-2  shows  an  exanple  of  a  ATP  Status  and  ATP  Queue  Information.  At  the  end  of 
the  status  of  the  last  active  ATP  the  report  prints  out  ATP  Queue 
Information.  This  section  shows  for  each  active  ATP,  the  number  of  unit 
trucks  serviced,  the  average  wait  time  and  the  maximum  wait  time  for  unit 
trucks  in  two  categories  -  maneuver  units  and  artillery  units. 

c.  ASP  Status.  For  each  active  ASP  for  each  anmunition  type  stocked  this 
section  of  the  report  details  the  followinq:  number  of  trucks  waiting  for 
resupply,  number  of  rounds  currently  in  stock,  demand  of  trucks  waitinq  to  be 
serviced  (in  rounds)  and  number  of  rounds  due  in  to  the  ASP.  Figure  7-3  lists 
an  example  of  this  section. 

d.  Unit  Truck  Resupply  Information.  For  each  type  of  unit  (see  paragraph 
4  for  unit  types)  the  following  is  recorded:  trips  to  an  ATP  and  average  trip 
time,  trip  to  an  ASP  and  average  trip  time,  percentage  of  trips  which  went  to 
an  ASP,  time  spent  in  reloading  weapon  systems,  total  time  all  trucks  for  that 
type  were  available,  total  time  when  all  trucks  were  idle,  and  the  percentage 
of  time  trucks  were  idle.  Also  printed  are  truck  movement  data  for  each  unit 
type  showing  for  each  type  of  move:  number  of  trucks  sent,  number 
interdicted,  number  which  needed  maintenance  and  the  average  travel  time  for 
the  type  of  movement  types.  See  paragraph  4  for  a  description  of  movement 
types.  Figure  7-4  is  an  example  of  unit  truck  resupply  information. 
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8.  DATA  SENSITIVITY.  Much  of  the  data  used  in  ARM  is  Scenario  am-.., 
dependent.  As  such  this  data  varies  greatly,  dinendinq  on  the  situat in., 
simulated  and  is  subject  to  user  control.  Some  data  however  is  der-i <e..- 1 
usage  in  most  ARM  runs.  Described  below  is  som^  of  this  data. 

a.  Weaixm  load  tines.  The  time  require  i  to  set  up  and  load 
based  on  data  obtained  from  appropriate  schools  and  centers.  A  data 
sensitivity  run  was  made  adding  ten  percent  to  each  of  these  t.  ones  an  . 
tire  model  for  twenty-four  hours  of  simulated  combat  (h  CIS).  Mo  srqnr  ..  a; 
change  across  the  force  was  noted  in  total  current  supply  on  weapons  for  i! 
units. 

b.  Truck  travel  times.  The  speeds  at  which  trucks  travel  (prirojr •  ;;. 
secondary  road  speeds)  were  average  values  obtained  from  the  Transpo;  ..  t 
School.  In  making  a  sensitivity  run,  ten  per  cent  was  added  to  these 

and  across  the  force  no  significant  change  in  total  current  supply  on  r;|- 
weapons  was  noted. 

e.  Reload  times  for  unit  trucks.  The  times  spent  in  resupply inn  . 
trucks  at  ATPs  and  at  ASPs  are  based  on  data  obtained  from  the  vissiie 
Munition  Center  and  School  (MMCS) .  When  ten  percent  was  added  to  thesi'  r i . 
no  significant  change  in  total  current  supply  on  weapons  across  the 
could  be  noted. 

d.  General  comments.  Sane  data  values  maintained  in  the  data  base 
as  ammunition  codes,  unit  types,  truck  types,  and  status  and  mission  of  rru 
are  somewhat,  arbitrary  (see  chapter  5  for  current  values) .  CARF  SHOOED  'V- 
TAKEN  IN  ALTERING  THESE  VALUES.  Parts  of  the  logic  flow  of  ARM  use  these 
values  in  critical  decision-making  processes;  therefore  chances  to  the  eo-'v 
would  be  necessary  if  they  should  be  altered.  Tt  is  sugqes  that  the  use 
contact  CACRA,  Ft.  Leavenworth  before  changes  are  implements. 
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.1 .  Background.  It  is  a  known  fart  rim  ;  ■  ’  '  •  •  -  •:  ••  rv-  on  <"<  rim- 

with  each  unit  based  upon  type  and  i ivo i  c;  vrat-  Nior.  s- gum  nod»l:: 
that  simulate  division  or  corps  wargr-nr-.-.  <io  ;•  :■■•{■  >  aim-v  '  >'•- 

consumption  data  that  is  believabl r  and  ' of  •:>]•■'  •  -■  ■  ;  oa;t>'-n  wm 

101-10-1  is  out  of  date  and  not  useful  ror  cm  -yea,-  planning  where  new  weapons 
systems  are  being  played  against  a  target  r : oh  rlui-ar.  The  OAA  rates, 
al though  developed  for  the  out  years,  m-:u  -1  1  m-v  ar-  i  of  utt  ie  value  in 

combat  development  work,  particularly  -in, rut 1 1  •.  i-> .  i  manor-  nr-v  .-is.  W’surxdv 
analysis  cannot  be  conducted  based  on  180  day  a-'-  :  the  con ;  m-  arms 

schools,  on  the  other  hand,  generate  mere  .rai  i s*  ;<•  < ■•••iv  m-of  on  r  ites  fr'i"* 
their  high  resolution  models.  Pate"  vh  r.  doy--  -.»•  v/hi  ref  Led 

the  variability  of  unit  consumpt  ion  and  i  m>,  -  :-r-  :•!  •  ;■<  :c 

expenditure  rates  of  higher  resolution 

2.  Basic  Ammunition  Consumption  P  •  r  -A  ■  .  w-re 

asked  o  develop  windows  -  i.e.  nvasr  id-'  o-nh' 

expenditure  rate  for  their  respective  raicr  '  . .  ,  a  var  icnv  of 

combat  conditions.  These  condition"  were  r.  ,  -.n  of  i  he 

following: 

Combat  Posture:  Delay,  Intense  iv-fc-uv.  -  hi  ,i- «.  ):  ?  or..-  .  -track 

MOPP  levels:  1  (Actual  MOPP  level  1  *  ' : 

2  (Actual  MOPP  ic  el  ?,  /,  -V; 

Since  the  scenario  used  in  ARM  runs  \ isrtc  1  r m  d  '1  dr  lav.  mid 

defense,  and  light  delay  intensity,  values  for  uu.;i  riven-  '  'orrovnrt  ion  were 
developed  by  taking  65  percent  of  the  mid-point  of  tiv  !'•■"•  '  :y  ac-i  i  nr.en.se 
Defense  windows  and  establishing  a  range  eonnxu  mle  ! i  iv--  mme.  of  of  two 
windows.  A  light  delay  window  was  developed  by  using  20%  ■••f  f  he  mid  point  of 
the  delay  windows  and  establishing  a  comparable  range  tor  scenario 

used  did  not.  list  visibility  conditions,  these  caramel--  a:  w:  r-ol  used. 

3.  MOPP  Degradation.  MOPP  4  values  were  computed  ar  fm  ’  ;wr  :  0.?  for  )fu 

day  in  MOPP  4,  0.5  for  second  day,  0.4  for  any  success  i  vc  'lav;,  'these  values 
were  applied  to  the  mopp  level  1  rates  wnenevei  a  unit  wa  in  ;  MOPP  A 
condition. 

4.  Distribution  of  Demand.  In  addition  ro  the  daily  "ov  net  weapon  system 
and  MOPP  degradation factors ,  it  was  necessary  .o  distribute  he  dai Iv  rate 
over  the  daylight  and  nighttime  portion  of  the  24  hours  of  ceswur.  It  is 
assumed  that  60%  of  all  ammunition  is  fired  during  daylight  hours;  40%  at 
night.  For  artillery  units  firing  different  types  of  ammunition  (i.e.  HF, 

I  CM,  RAP,  COPPERHEAD,  etc.)  the  daily  rate  is  further  list  i  b  >  ii>  ,i  amongst  the 
different  types  under  consideration  according  to  the  formula  q,.ven  from  the  UR 
Army  Field  Artillery  School.  Figure  A-l  shows  the  ammunition  consumpt ion 
windows  (MCPP  Levels  1  and  2).  A  detailed  methodology  of  ho-'  the  demand 
generation  program  used  in  conjunction  with  ARM  works  is  aval lablr  in  chapter 
4  of  this  volume . 
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SUBJECT:  Documentation  of  the  Ammunition  Resupply  Model 
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Included  find  your  copy  or  copies  of  the  latest  (May  1983)  three  volume  docu¬ 
mentation  of  the  CAORA  developed  Ammunition  Resupply  Model.  For  those  not 
already  familiar  with  the  system,  this  supercedes  all  previous  ARM  documenta¬ 
tion.  For  others  it  extends  earlier  documentation  to  include  several  signifi¬ 
cant  program  modifications  and  the  use  of  a  different  computer  system. 
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